下一座圣杯 - 2019

今年的圣杯文章拖延很久，原因是笔者公司也在做这方向产品，所以故意押后几个月才发：先看清市场有没有跟随者以及其理解程度。毕竟创业公司要辛苦谋生度日，竞争态势也需要时刻注意。每年的圣杯文章预测两年后初见成功的新安全产品。今年笔者挑选的方向注定是个红海；初创公司要谨慎进入，因为必然会直面大厂发起的凶猛竞争。

应用安全的发展

最近十年，应用安全从未缺席行业热点关注。公众号留言希望笔者写写有关应用安全的要求也从未间断过。还记得2015年关于安全新趋势的文章吗？数据是新中心、身份是新边界、行为是新控制、情报是新服务。每一点都代表着创业公司的市场机会。唯独没有应用安全。应用安全不重要吗？当然不是。软件定义世界，没有人会否认软件自身安全性的重要程度。可惜的是，在2015年，笔者并没看到应用安全出现新技术变革。基础设施演进给应用安全市场带来了新机会，也只是交付方式的改变，导致新增容量大部分被云基础设施大厂瓜分殆尽。过去数年间，缺乏技术变革，还要面对CSP逐步蚕食份额，应用安全厂商感觉压力山大，都在发愁如何把乏善可陈的产品做出亮点。在此大环境下，专注技术创新的初创公司也很难孵化出明星。

为了佐证此论断，我们不妨对比2004年与2017年OWASP Top 10的变化。下图中，笔者用箭头画出了相差十三年两份列表的内容对应关系。透过表象看实质：仔细研究其详细解释，就会发现除了列表标题文字表达有些许差异外，具体安全控制点在两份文档中几乎都可以一条不落地找到。

例如，2004 A10 Insecure Configuration Management具体解释中第一点即明确提到unpatched security flaws in the server software，与2017 A9 Using Components with Known Vulnerabilities并无本质区别。2017 A4 XXE是新出现的条目，自然是由于XML广泛应用所引起的，但是让我们看一眼2004 A1 Unvalidated Input的解释：Attackers can tamper with any part of an HTTP request, including the url, querystring, headers, cookies, form fields, and hidden fields, to try to bypass the site's security mechanisms. 显然，XXE只是其中一种表现，并不新鲜。而反序列化漏洞代替缓冲区溢出，揭示着应用系统架构的变迁，Java等开发语言逐渐占据统治地位。消失在前十的2004 A9 Application Denial of Service，把它挪到2017 A11的位置，相信绝大部分读者都没有异议。2017年真正意义上新出现的条目只有一个：A10 Insufficient Logging & Monitoring，而这正是整个安全业界对于防御和检测的心态发生了根本转变才有的认识。

不知道各位看官有没有像笔者当时一样感到十分惊叹。假设2004年你已经掌握了Web攻击的基础知识并充分实践，恭喜你，十几年后，你即使并没努力学习新技术，即使一直原地踏步，也不会被无情淘汰。这在飞速发展的计算机领域简直太不可思议了。举个例子做对比，同样这十五年间，操作系统等软件的安全性至少上了四五个大台阶，如果你不能持续跟进新技术发展，内网横向移动必然举步维艰。

回顾应用安全领域的标杆产品WAF的发展历程，也可以看到类似现象。开源ModSecurity发布于2002年，虽然易用性和支持性比不过商业产品，但事实上一直代表着此领域的技术发展水平。把时间拨回到2015年，笔者能看到的创新，也只有SQL注入的词法分析，始于2012年开源的libinjection。这个目前WAF厂商还在重点宣传的新功能，ModSecurity在2013年初就已经集成并提供。题外话，libinjection的作者后来作为CTO共同创立了引人注目的Signal Sciences，成为WAF市场后起之秀。在此之后，ModSecurity于2014年引入模糊哈希方法ssdeep检测webshell，其所用技术CTPH早在2006年面世，实际效果差强人意，难以大张旗鼓宣传。从那时到现在，大家又记得WAF检测技术出现了什么新变化吗？

笔者还观察到一个有趣现象，无论美国亦或国内，如果你跟NGFW或其它产品方向的领先厂商的技术人员交流，总会有一种感觉，他们对WAF根本不重视，言谈中隐隐流露出认为其技术老旧缺乏壁垒、市场规模有限、所以不愿意投入的意思。

但笔者十分重视WAF市场。熟悉的朋友都知道我近几年多次讲到十分后悔2015年纠结了半年时间最终没有坚定投入WAF产品。那时候，我看到了WAF在国内市场的巨大潜力：少有的预算增速和预算份额远超美国市场的安全产品，这是由于当时国内电商和线上业务发展速度已经显露出全面超过美国的迹象。但是我也看到了缺乏技术革新带来的产品同质化严重，同时高估了大厂的产品研发和市场进攻执行力，还有重金砸销售与那时公司运营模式不同的挑战，等等各种貌似正确的理由，最终错失了一次市场爆发机会。每日三省吾身，交过学费的自然要牢记并且避免再犯错。这几年来，笔者一直念念不忘试图寻找进入应用安全领域的切入点。

上文提及，云增量被CSP吃掉。早在2015年，笔者就认为云WAF位列云安全产品收入前三，应是云服务商重点投入方向，参见本公众号文章《安全，是云基础设施的核心竞争力之一》。那年，业界还在争论，云服务商应不应该做安全、能不能做好安全。白驹过隙，四年后市场给出了强有力的答案：今年各路分析师报告，全球前十WAF厂商里有一半是云基础设施服务商。新机会由交付方式改变而引发，并非技术变革，导致WAF市场发展不是创新驱动而是投资驱动，因此头部CSP能拥有巨大竞争优势。

应用安全其它领域的需求亦很强劲，只是难以规模化成长，独立支撑起一个上市公司的难度颇大。例如RASP，2015年RSAC创新沙盒冠军Waratek，现在也转向RASP与WAF结合，走Signal Sciences的道路；成立十年之久，规模却落后太多。近两年新趋势，厂商同时提供RASP和WAF集成，弥补各自不足之处。Shape Security当年猛吹动态变形，究其原理也是RASP路数，想做到上市也困难重重，历经转换方向尝试，到现在早已改成RASP+WAF+SDK。Imperva起家其实是靠数据库安全。美国WAF市场启动与国内同步甚至略慢，到现在也已经变成红海，收购整合一直在进行中。另外，今年创新沙盒入围者ShiftLeft，数学方法辅助自动化代码漏洞挖掘，笔者虽然很喜欢其技术，但也知道很多美国投资者并不看好代码审计类产品，因为他们投了近二十年的代码审计初创公司，最好的结果是被收购。应用安全厂商面对窘境，无不积极寻找转折机会。横跨半步，已成为安全行业扩大规模的普遍策略，常见的有，威胁情报厂商销售IDS，漏扫厂商通过DAST产品进入SDL，代表厂商如Rapid7，等等。

洋洋洒洒写了两千多字，显然不是废话去浪费大家时间，而是要为中心思想做铺垫：虽然过去十年美国市场涌现出不少应用安全创业公司，但成功者十分稀少。就在眼下，应用安全领域出现了一个少见的拥有巨大市场空间的创业机会：API安全。新应用风险，新安全战场。或许很多读者已经猜到此答案，因为从去年底开始，笔者已经多次在小型沙龙和大型行业会议中公开介绍过API安全的基础知识。新基础设施必然会带来新安全产品机遇。作为连接一切应用并交付数据和功能的方式，API已成为安全团队不得不重视的关键风险控制点。

新形势与新机遇

过去五年，云计算已经深入到数字化经济基础设施的方方面面，市场竞争态势的巨大变革导致诸多厂商盛衰沉浮，不乏跟不上趋势从此一蹶不振的。未来五年，影响深远的技术架构变革会是什么？一千个读者心中有一千个哈姆雷特，不同解读在所难免。但是，微服务、Serverless、边缘计算，应该能覆盖大部分读者心中的答案。听起来区别颇大的三个方向，却都有一点共同特征：API是必不可少的基础模块。

业内容易有个认知误区，微服务常常被认为等同于容器，其实不然：容器只是提供了大规模部署的便捷管理方法，容器离开微服务架构就没有大发展机会，而微服务离开容器仍将继续快速前行。容器的易用性必然会带来额外资源消耗、性能波动、治理复杂度、以及其它相对应的局限，因此如今也有企业在部署微服务时，出现从容器回退到虚拟机甚至物理机的现象。或相反方向，使用更抽象化更易管理的计算方式支持微服务，类似Serverless用于搭建Microservices， AWS已自成体系：Lambda、Fargate、Aurora Serverless、EventBridge、Kinesis等等。事实上，微服务架构的核心是网格mesh，网格的连线采用API最易达成管理。因此，没有Kubernetes照样可以使用微服务，没有API就没有微服务。业界有些专家坚称，微服务不过是SOA旧瓶装新酒，此论调与当年将云计算等同于虚拟化一说惊人雷同，迟早会被证误。笔者认为，SOA所描述的数据总线已经过时，将被支持网状通讯传输的数据平面所替代。原因有很多，既然是安全行业公众号，本文就只讲从安全角度出发的一点：SOA数据总线架构无法满足数据安全合规要求。只有升级到点对点的服务网格，使用分类分级的API，严格认证身份并充分鉴权，遵循最小限度使用数据的原则，才能灵活达成日趋严格的数据资产内控目标。下面借用一张示意图说明API在微服务架构中的无处不在。

闲扯两句，近两年来感觉国内云厂商能力与AWS和Azure相比差距越来越大。很多人并不理解什么是“跟随者战略”。并不是友商今天发布一项新产品，咱们自己10个月后也发个新闻稿写页ppt就能搞定。有些新产品需要起码几年时间去开发，大神再多的研发团队也没办法创造奇迹。真正的跟随者战略，要提前三五年识别友商的中期战略，还原其产品规划路线图，然后自己才能布局资源投入，达成落后一年跟随领导者推出新品的目标。不踏实做竞争分析的功课，等人家产品都发布了，自己手忙脚乱硬上，顶多是学个皮毛，凑合做个界面，面子里子本末倒置。还有人觉得AWS发布Fargate是被Kubernetes逼迫的无奈之举，App Mesh无法面对Istio，事实上只能说他根本不理解云计算和AWS战略，不过是鹦鹉学舌般喊名词扯大旗。Kubernetes是很凶猛，Istio是很牛逼，但就像十年前大家还会聊起Xen和KVM，现在AWS云上绝大多数客户不会提及Hypervisor而只知道EC2一样，五年后，客户只要能在AWS上轻松跑起来容器并编排应用之间网络连接就好，人家只需要知道Fargate和App Mesh，管你下面用的K8s/Istio还是什么其它架构。就连掌握K8s的Google也推出了相同产品Cloud Run。如果连行业领导者的战略都看不懂，就不要奢谈什么跟随者策略。计算抽象化，自打计算机问世后就一直存在，无法阻挡也不可避免，在云上也没有例外，Serverless已经被公认为大势所趋。

Serverless，或者有人叫Function-as-a-Service（其实范畴略有不同），本来就是构建于API之上且以API方式提供功能交付，所有后台计算服务器都被抽象化，用户看不见也不关心，自然不用多说API在其中扮演的重要角色。边缘计算，也不可能有独立的孤岛设备，边缘计算节点之间以及与云上中心服务器的所有交互都是通过API实现。

让我们再来看看更多热门应用场景：人工智能AI平台能力都是通过API来交付的，无论是图像识别还是反欺诈；今年炒得火热的中台，实质上是把后端能力标准API化；供应链中的数据交换，毫无疑问也都是API；不一而足。在数字化转型过程中，API已经成为不可或缺的基础设施。

既然API应用广泛是大趋势，那做API管理平台是不是比API安全更有前景呢？去年早些时候，笔者与几个做投资的朋友聊起此创业方向时，狠狠泼了一盆冷水。首先，去年开始做明显已经晚了，要做也必须在巨头动手之前，先发才能有机会抢占市场。早在三四年前，国外巨头已经纷纷开始布局，参见下表。其次，API管理服务受客户导流影响显著，初创公司需要付出可观的客户获取成本，而这方面巨头拥有无可比拟的优势，无论是私有化部署或者云交付。第三，开源方案已经很成熟，Kong、WSO2、Ambassador、Tyk、Zuul等各有千秋，令业务自建门槛大幅降低，有一定自研能力的企业往往不会选择外购。

国内市场还要面临更多的挑战。尤其难免会遇到拷问灵魂的问题：巨头入场之后，创业公司的竞争优势如何体现？此方向上，很难建立有效的技术壁垒，无论是性能还是功能，想突破Nginx衍生平台的水平，真不是三五个核心团队成员一两年能搞定的。想做开源发行版定制？Hadoop生态的颓势历历在目。此外，云厂商的标准产品会吃掉绝大部分中小企业的市场份额。还有之前已经成功的业务系统开发厂商，他们坐拥前期积累的成本优势，必定横移半步正面竞争。API管理平台由于与业务系统关联紧密，客户很高概率会要求定制开发，这对创业公司既是机会又是陷阱。一方面即使巨头拿到订单也可能不愿意做，甩给小公司，不过这样拿到的单子交付压力大，毛利率较低，另一方面，直销往往又需要付出高昂的获客成本，非标准化且交付要求高的产品，走渠道只是空想罢了。简而言之，规模发展速度受限，利润空间堪忧。

但凡存在基础设施演进变革，安全创业的机会就少不了。随着API迅速成为内外部人员和应用服务之间交换并使用数据的主要通道，管理层越来越担心它所带来的内外部威胁。API安全由于坐拥安全市场区隔的独有特性，竞争态势会远远好于通用API管理市场；而API管理厂商虽然会提供部分基础安全能力，例如用量限制、抗DDoS、防bot、身份认证和鉴权等，但通常也没有能力太过深入去抢安全厂商的饭碗。既然如此，接下来需要考虑的便是，API安全应该如何切入呢？

跨细分领域且跨基础设施

虽然本文以应用安全开头，不过API安全可不仅仅局限于应用安全，还横跨数据安全和身份安全领域，这就令其切入点变得多且分散。任何只关注某一细分领域的API安全产品都不是完整的，客户要求的是能处理此场景中尽可能多风险矛盾的完整解决方案。创业公司可以根据自己历史积累的竞争优势，灵活选择入场方式，然后再横向移动至相邻细分领域。例如笔者公司的API安全产品便是由数据安全入手，随后引入认证和鉴权相关风险的检测，目前在完善应用安全方面的覆盖。

照此逻辑，WAF大厂Imperva从应用安全入手非常自然，API安全已经位列其应用安全类目下的顶级产品线，与WAF并列。之前在Web攻防领域积累颇多的厂商，自然首先宣传对API攻击会造成巨大危害。Imperva产品彩页包括四个要点：阻止API相关的严重攻击、构建基于OpenAPI规范的积极安全模型、集成安全性至API生命周期管理、网站与API的统一安全解决方案。是不是感觉描述十分简单？由此可见Imperva也才刚刚开始。

上图说明了API安全在Imperva整个纵深防御产品体系里的位置。

Web安全已有超过15年时间的高强度对抗，而API对抗不过才刚刚开始，程序员们都没经过实战演练，很容易出现各种漏洞。因此，在目前阶段，攻击API很容易达成满意结果，利用已有渗透测试工具都能获取可观的产出，典型的a low-hanging fruit，年底冲业绩的红队不妨一试。

说到这里不能不提OWASP组织的API安全前十列表，如下图所示。在笔者看来，此列表过于注重攻击防守技术，缺少对业务风险的理解和支持，安全团队难以使用类似口径向管理层汇报，立项申请预算都要颇费一番周折。因此，笔者从商业风险纬度出发，总结了五点管理层关心的、会造成明确业务损失的、并且有缓解措施落地的API安全威胁，在多个场合公开介绍过。限于篇幅，此处不展开细讲了。

大家不妨对比一下OWASP Top 10与OWASP API Top 10之间的区别，篇幅所限这里不展开详细讲了。

今年RSAC创新沙盒入围厂商Salt Security是OWASP API Top 10的赞助商之一，号称可以发现攻击者侦查API的行为，从其思路来看也是应用安全方向。很遗憾的是，过去一年中笔者在各展会上四处寻觅却都没看到其产品演示，这情形也十分少见，令人不禁心生疑惑。

从身份安全迈入API安全也是一条可行之路。API离不开身份认证和鉴权，IAM厂商天生就有现成客户群体沉淀，可交叉销售的新产品线是许多管理层扩张战略的最爱。Ping Identity首先通过PingAccess为客户提供API中的权限管控能力，发现协同效应后，进一步收购Elastic Beam以完善API安全解决方案：打包成下图中的PingIntelligence产品线。

上面的另一块拼图组成部分，便是对API使用过程中的数据流动的监控，产品线名称为PingDataGovernance。笔者不愿意过分夸大数据流动的风险，虽然五年前我们产品已经有了数据地图的功能，但从来没大张旗鼓宣传也没必要去吓唬用户。原因很简单，不分重点监测数据流量的工作，投资回报率ROI较低，不建议资源紧张的安全团队超前考虑。安全行业中颇有一些貌似简单直观的概念，乍听上去很有道理，人人都能理解并附和讨论几句，其实却经不起推敲。安全发展到现在，再出现简洁直观的体系架构非常困难，至少很难发源于普通从业者。最近几年火热的诸如零信任和ATT&CK等新思路，有哪个是能轻易理解上手的，又有哪个是能快速落地的，又有哪个不是投入巨资多年积累的？现实当中，企业大部分的数据流动场景的风险极低，盲目检测与大海里捞针没什么区别，短时间也许可以赢得一些赞誉，长期产出难以预测和衡量，无法得到管理层认可。试图掌握大型企业中的数据流动？安全团队不妨先厘清预算，带宽、存储、算力是否足够支撑，最关键的是，要有足够的员工编制确保日常运营，再考虑检测出的风险数量是不是足够多到能说服管理层进而持续支持如此之大的资金投入。以为是蓝海创新，其实是高投入低产出的无底洞。几十年来，安全预算首重边界防护是非常有道理的，因为那里是ROI最高的所在。延续这一思路，发现数据流动风险，想要出业绩，最重要的是监控边界处发生的恶意技战术，办公网自然是DLP，而业务系统领域API当仁不让首当其冲。

API安全从数据防泄漏角度切入对管理层也拥有非常吸引力。2018年，由于API问题造成的知名数据安全事件发生了很多起，小额社交支付Venmo泄露了数十万条交易细节，T-Mobile泄露了230万用户敏感数据，Facebook泄露了超过3000万账户，USPS则泄露了约6000万账户的数据。2019年，澳大利亚最大的房地产评估公司LandMark White出现API漏洞，导致房地产估价细节和客户信息泄露；调查发现，出现的问题根源在于，最初设计只能在内部使用的API，被攻击者从其域外部访问；此事件严重损害了该公司声誉，客户和银行合作伙伴争相寻找替代方案，最终导致首席执行官辞职。不幸的是，此类API数据泄露问题十分常见，也不是权限检测就能发现的，往往需要依赖行为分析才能捕获。

除了横跨三个细分领域之外，API安全还有更多难点，需要适应多种不同时期不同架构的业务应用。传统行业拥有大量历史留存的基于SOAP的老旧业务系统，并不遵循OpenAPI，甚至不使用REST API，而是WebSockets传输XML数据。此外，JSON、Protobuf、GraphQL、RPC、HTTP/2等等，很多时候开发人员都是拿橘子跟苹果对比，概念范畴都无法对齐，API安全产品处理起来更是复杂。大部分国外创业公司只专注于一种接口，但在国内恐怕行不通。

下图的演讲标题看着眼晕不？是不是有不忍直视的拉郎配般的酸爽？如果公司里有个盲目崇拜大厂不停尝试追赶实验室技术的架构师，那安全团队一定有种被无情架在火堆上炙烤的感觉。

此外，API使用场景广泛，需要厂商有全面覆盖多种不同基础设施的产品能力。最简单的部署方式自然是网络流量镜像，还原HTTP流量中的REST API通讯，大家都觉得容易，但内部员工使用业务系统API的TLS加密流量，能正确应对还原的厂商就不多了。JSON能描述的数据格式简单，业务系统需要传输大量PDF表单和Office文档，内容是否敏感也需要筛查。使用S3兼容对象存储、CIFS/SMB、NFS等存储设施中转数据，也需要能进一步识别。微服务sidecar镜像过来的流量得能接住，API网关也需要提供插件支持，分布在全球各地的流量探针要考虑如何汇聚海量日志，5万正式员工加3万外包电脑使用API的行为如何准确发现异常并定位，等等，各种各样的复杂情况都需要考虑到，厂商产品化工程压力山大。

只监视自己公司内部业务系统之间的数据流动？那顶多覆盖了5%不到的风险区域。真正重要的风险不是简单标记数据传输就能描述清楚的。例如，呼叫中心客服虚拟桌面系统和后台业务订单系统每天传输100万条客户数据，这俩系统之间本来就应该有数据流动且看起来完全正常，那就没有风险了？真正的威胁隐藏于每一条API使用的过程中，可能只有1%的数据交换是风险，特权用户恶意下载、账号泄露盗用、用户权限提升、访问鉴权缺失、敏感数据意外暴露、隐蔽后门接口等等，都可能造成严重后果，这可不是只看数据流动就能发现的，需要从身份、应用、数据三个角度出发综合考虑才能有效检出。

境况不佳的API安全初创公司

创业首先要选好方向，否则血泪一把。Chronicle被抛弃一点儿都不令人意外，就算是含着金汤匙出生的行业大佬，妄图不顾市场规律逆势而行，也都会撞到头破血流惨淡收场，类似故事在各行业都是持续上演屡见不鲜。API安全并非新事物，历史悠久，七八年前就有，但直到今年才初露峥嵘，刚需且市场潜力巨大，是创业的好机会。同时，API安全注定是红海。若创业选择此方向，必须认真考虑自身团队的核心能力是不是有机会在千军万马中跑出领先身位。笔者注意到美国有两家此领域创业公司已经解散关门，大部分团队都出现了增长缓慢和融资困难的现象。所以，笔者去年底也斟酌良久才确定投入资源。创业维艰。过去几年相对准确的预测，并不代表笔者这次不会犯错误，想进入此方向的读者请自行认真考虑并承担风险。

想做好API安全产品还是蛮难的，领域多且复杂，功能范围分布较广，门槛较高。此处，我们粗略看看几家被分析师提及的创业公司的产品方向，读者可以感受一下不同厂商之间的区别有多大。另外也能得出不要盲目崇拜国外厂商的结论，因为大部分做得实在很一般，分析师地域偏见十分明显。

42Crunch

已有4年历史，专注于OpenAPI，总部位于伦敦，团队经验丰富，前Axway和IBM等经历，但融资并不顺利。其产品提供三种能力。首先，根据OpenAPI标准规范，检查提交的API定义是不是满足安全要求。其次，动态检测API服务是否遵循API定义，报告总结扫描内容和方式，包括响应时间、收到的HTTP状态代码、以及意外响应状态代码等。最后，API防火墙，使用C编写，Docker镜像，sidecar牵引流量已经是标准配置，只能工作在Kubernetes环境下，必须连接42Crunch的平台。笔者听过其创始团队的几个议题，感觉他们确实对API实践经验丰富，只是这产品形态距离进入大规模推广阶段还有不少阻碍。笔者很难看好其未来发展，团队还需要主动寻找转折点。

Aiculus

2017年10月成立，位于墨尔本，融资历程惨不忍睹。其使用人工智能AI自动检测和阻止试图盗取数据和欺诈性的API使用。下面一段是Aiculus宣传的机器学习实际用例。

利用8000+用户认证和访问日志的历史数据对神经网络模型进行训练。历史数据由13个特性组成，包括用户请求访问系统或进入物理建筑时收集的用户属性参数。利用这些数据对机器学习引擎进行训练，使其能够准确预测平台上的访问分配、访问拒绝、再认证和用户意图。

“进入物理建筑”？门禁确实勉强能跟API扯上关系吧。8000+用户在澳大利亚算个不错的案例了，在国内真不是能值得吹嘘的规模。读者可以看出，Aiculus从身份安全切入API安全的路径选择。

Data Theorem

业界一直有个传说，不需要融资就能快速发展的创业公司才是真正生猛强大。大家听听笑笑也就算了，别当真。不烧钱还想高速增长，在今天的国内安全市场无异于天方夜谭，大部分企业服务公司烧钱还见不到增长呢。不过凡事必有例外，Data Theorem就很神奇，员工规模达到300人，却没看到任何公开的融资信息。2013年成立，最初做移动安全，目前已转向应用安全，API安全是业务重点。创始人为20年连续创业者，有两家公司被收购的历史。

Data Theorem提供两款产品，API Discover和API Inspect。Discover能持续自动在客户公有云基础设施中发现新的API、记录已知API的更改、以及与这些API相关的其他云服务。Discover产品还能让安全和运营团队发现Shadow API，基于云的分析引擎不断扫描Serverless应用程序，一旦发现就会生成警报并通知安全团队。Inspect分析引擎持续对API的身份验证、加密、源码、和日志进行安全评估，确保API操作功能与其定义相匹配，并报告关键漏洞警报。

下图是Data Theorem建议的API安全实施步骤，没有常见的咨询机构的高大上体系，只能做落地实用参考。

imVision

虽然融到钱但很少以至于日子过得十分惨淡的以色列厂商。其产品介绍无足称道，笔者都提不起兴趣多写两句。生搬硬套的人工智能驱动，如下张幻灯片讲自然语言处理识别API模式。

FX Labs / CyberSecuriti

落寞的硅谷公司，融不到钱，创始团队已有变动。大家看到这里是不是已经对API安全创业失去信心了？这个公司产品以漏洞扫描为主。

Sapience

类似的漏洞扫描方向。同样没钱的小团队。

CloudVector / ArecaBay

今年RSAC上笔者就注意到此家，2018年正式成立，华裔创始人，行业经验丰富，参与创办过Netskope，再之前是一家被McAfee收购的团队成员。直到今年11月才宣布获得500万美元投资，公司改名，同时空降CEO和CFO。其产品主要包含三种能力：

• API检查模块AIM：全自动微传感器模块持续发现连接到企业资产的所有API，包括影子API。

• 深度API风险追踪器DART：深度监控模块将经验证过的机器学习应用于客户特定的API蓝图，驱动API风险的自动识别，更重要的是还能实时检测对手尝试侦查的行为。

• API响应模块ARM：实时响应模块能针对API滥用强制实施安全策略，是完全解决OWASP API Top 10的唯一解决方案。

此处放一张今年3月ArecaBay宣传材料照片，限于篇幅就不放更多资料了。

各位看官有没有很失望，以为分析师推荐厂商列表能让人眼前一亮，实际看下来大部分都是三脚猫水平，要是拿这么低完成度的产品去忽悠国内大甲方，还不得被口水喷到体无完肤。这也从另一个角度说明，现在安全行业需求水平日益提高，想做好一个企业级产品，最少投入的资金，在美国至少两千万美元，在国内至少四千万人民币，不融资几乎不可能。想反驳的，请别用开源项目糊弄产品靠销售硬塞的例子留言给笔者。如果吹牛巨额融资花了一个亿重金精雕细琢出一个产品来，也请投资者擦亮眼睛避免入坑，原因很简单，国内安全产品的毛利水平根本撑不起如此挥霍。

笔者研究后发现，论API安全产品质量，目前美国市场上的几个大厂明显优于大部分创业公司，恐怕国内也会面临相同局面，至少头部公有云厂商肯定会自行研发，自用然后尝试输出。因此，创业团队要对潜在竞争有清醒认识，并拥有足够信心在产品上直面竞争。

市场大势，此消彼长。五年前做API安全，毫无疑问会成为被拍在沙滩上的前浪，那时的契机是WAF。现在进入API安全，机会与风险并存。做好准备面对大额资金投入的一线厂商吧。小公司如果能过好产品关，即使身处激烈竞争的红海，也许运气会和你站在一起，成功可期。