给大家分享的内容分为三个部分
第一个是在安全行业，开源产品的简单概况，包括一些国外的开源的产品，以及国内整个安全行业的开源和国外有什么不一样的点。
第二个是为大家分享一下洞态IAST整个开源的过程，从开源到现在经历的事情。如果说有小伙伴想在安全行业里面做开源产品的话，还是有很重要的参考价值。
第三个是商业化，现在大家去聊开源，我觉得很大一部分人都是按照自己的情怀去想、去做的，在安全领域或者在开源领域发出自己的声音，但是对于一个商业公司来说，开源产品的商业化其实是绕不过去的一个点，在这个部分会给大家分享我们在商业化上面的一些思考以及洞态IAST在商业化的想法。

从目前来看，安全领域的开源项目相比于非安全领域是比较少的，像WAF、漏扫工具，虽然国内国外还是有很多的，但是相比于一些非安全项目，像数据库、中间件、云原生等，安全领域开源的项目数量是相对比较少，像国外比较有名的ModSecurity，国内的蜜罐HFish，包括我们今天会为大家分享的洞态IAST，其实都属于比较典型的开源产品。
国外的开源产品从产品的完整度、产品的生态来说，比国内要强很多，国内还是处在一个相对来说比较早期的阶段。
国内外的整个氛围差距是比较大的，国内对于一些防守型的产品来说还好，对于一些攻击型的，因为国内一些法律上的问题，在开源数据、把代码完全开放出去是有法律风险的。
国内的安全产品更多的市场其实是面向于大的客户，可能是政府或者说一些大的央企等传统客户，即便是防守方的一些安全产品去开放，对于自己的客户来说，其实也会有比较大的心理负担，毕竟代码都是开放的，这种防守能力怎么去保证？
国内有一个和国外有比较中间态的一种状态，会在github放出自己免费版的产品，但是代码不开源，一个比较重要的原因是，大家对版权的保护意识并没有那么强，今年有几个事件会把这个事情往前推一步。
第一个是国内最近宣布了GPL协议的一个判罚，以后大家再去用开源软件的时候，如果不遵守开源协议，我直接去copy过来，直接就去改，如果说走到法院里面去起诉，大概率是会按照GPL开源协议去做判罚。
另外一个比较重要的一个事件，前段时间SkyWalking开源的代码被一家公司的员工拿去当自己的OKR的目标，改了改直接就去上线，甚至说重新发版，其实炒的是比较热的。
这些事件都标志国内整个的开源氛围慢慢变好，但是之前环境并不是特别好，所以就会出现很多中间态，比如说Goby、xray，大家最开始都会选择可以免费去用，但是代码是不开源的一种状态。

我在分享洞态IAST的整个开源的过程之前，我先为大家简单介绍一下IAST以及洞态IAST，我们在上线前去做代码漏洞扫描方式，比较常见的几种，一种是黑盒，一种是白盒。
黑盒有很多缺点，比如对整个测试环境的影响是比较大的，发成千上万的包去验证一个漏洞；另一个是整个扫描的时间是比较长，那现在大家都走DevOps流程，对于安全的同学来说，我要去卡一个点，你要给我留出多少时间来去做一个安全检查，其实在内部去做安全运营的时候，会有比较大阻力的。
那白盒也一样，因为有些误报，甚至说像CodeQL这种工具，需要花费人力去研究里面的规则，深入这个工具内部去做一些规则匹配，使用成本还是比较高的。
那这两种其实最终都没有办法在DevOps流程里面自动化的去完成一些漏洞检测，IAST是通过插桩agent的方式去非常高效准确的去完成一些漏洞检测，在插桩过程中，直接拿到代码的参数和代码的调用链，只根据当前的代码调用链去完成漏洞检测，相比白盒也可以拿到完整的请求的参数，所以整个检测的准确率是非常高的，而且不会像黑盒一样，就基于一些算法，根据当前的一个请求链路，可以实时进行漏洞的检测，其实在DevOps现在的阶段，IAST会比黑白盒都更适合用在DevOps里面，在商业前去做一些安全检测。
再介绍一下我们开源的洞态IAST，目前洞态IAST依旧是全球唯一的一款开源的IAST产品，本身技术壁垒非常高，我们在做的时候也有考虑过，是不是拿这种非常有技术壁垒，但又比较好用的产品直接去做一些商业化的变现？其实思考了挺多，最终决定还是直接开源出来。
洞态IAST是一个稳定性优先的IAST产品。我们了解到有很多IAST产品，更多的是以漏扫的补充来使用，主要用在一些传统的行业里面，如果说测试环境宕掉了，其实并没有太大的影响，因为IAST是要插桩agent，对代码的侵入性还是非常高的，其实对稳定性有非常高的要求，洞态IAST在稳定性上面是做了非常多的一些特性在里面，包括agent的整个的熔断的降级等等的。
IAST是非常适用于DevOps整个安全检测的利器，有很多在检测上面的优势。洞态IAST对一些像github、gitlab内部的CI流程做了一些非常简单的一键接入的集成，也支持云原生K8S下面的直接部署，在DevOps这种场景做了非常多的一些特性去支持，那其实是完全避开了简单的漏扫的补充性的产品特性。
还有一点是在大的厂商里面，或者说我们整个基础架构再往前调整的过程中，微服务以及服务拆分变得越来越普遍，未来也基本上会是按照这种架构去继续往前演进，那就会导致一个漏洞在产生的过程中，是没有办法去判定这个漏洞，它产生的上下游的调用关系是怎样的，那可能只是中间的一个服务出现了漏洞，那么最终暴露在用户端的一个漏洞的全链路的场景是怎样的，其实这个排查的过程成本非常高。
洞态IAST首先支持了在微服务场景下面，在跨服务之间的漏洞检测，一旦某个服务出现了漏洞，那么可以非常完整的展现出来这个漏洞进来以及处理、触发的完整的链路是什么，不仅仅是代码的调用链路，而且是微服务之间的请求链路。

那洞态IAST为什么会选择开源？我觉得首先最重要的一点还是情怀上面，我们觉得一款比较好用的安全工具，就应该是更加开放的，去解决行业里面的安全问题，这个是除商业之外，我们内心更想去做的一件事情。
从安全从业者的角度来说，目前国内因为政策上面的保护原因，像黑客、白帽子主动去渗透一些企业的漏洞，其实是违法的，即便他是出于好心的想法，我去帮你去找一下漏洞，如果没有经过授权，法律风险依然是比较高的。
站在安全从业者的角度来看，国内的互联网厂商，或者说一些有外部资产的厂商，整体的风险度是非常高的。我们内部也做过一些相应的测绘，这个在国内有互联网资产，并且在互联网资产上去报了漏洞的，企业数量大概是百万级的。
所以我们希望可以通过开源的方式，无需非常多安全知识，无需安全人员投入，就可以在上线前去解决绝大部分企业内部的代码安全问题，这个是我们想去开源非常重要的一个点，大家也知道这款产品做出来之后，壁垒也高，行业的需求也旺盛，直接去卖是可以变现的，我们先选择了去做开源的事情，希望可以通过这种方式让国内的安全的状态会变得更好。

从产品的角度来说，通过开源的方式，我们可以让整个产品和产品生态变得更好，最主要有几点。
开源之后，可以在github以及其他渠道非常快的收到企业的反馈，用户在使用过程中，会直接把它企业内部的场景，使用过程中的体验，他认为这款产品最好的一个状态应该是怎样的，整个产品的迭代效率是非常快的。
相比传统的软件来说，特别是安全软件，假如你今天看到了IAST的介绍，想去试用IAST这款产品，开源的洞态IAST你可以直接到github上拉下来，五分钟就可以去体验到；那非开源的产品可能要去打电话，等销售跟进、售前跟你讲PPT，讲完PPT之后大家再去约时间部署、测试，这一系列的事情时间至少是按周算的。开源产品对用户来说可以分钟级的体验到，对于产品来说也可以非常快速的拿到一些反馈，去做更精准的产品迭代。
还有一点是我们通过开源可以接触更多优秀的开发者，我们公司内部有一些开发者是通过社区面过来的，觉得这个产品还不错，然后过来一起去搞了，那外部的比如说我们会有一些开发者的双周会，大家每两周可以去碰一下，比如说Java agent、go agent的开发者，去定期去碰一下开发的计划，有一些外部的开发者可以非常方便地开发进来。
同样在企业这边，我们会和企业有一些联合共建的场景，那刚刚提到的agent的稳定性，是和58同城一起联合开发。这种稳定性的场景，对于乙方的安全公司来说，其实是很难去遇到的，只有在一些有比较大的服务的数量，比较多的测试人员，比较多的测试的项目的时候，才会有非常严苛的那种稳定性的要求。
我们在和58同城或者和其他的一些互联网厂商去聊的时候，大家都试用了市面上的各种IAST产品，基本上是很难满足自己对稳定性的要求，所以大家去一起去联合共建，把agent的稳定性做到一个非常高的级别，对产品来说也是非常大的正向的反馈。
当然我们也会有非常多其他的收入，比如说我们收获了更多的一些客户贡献过来的检测的场景，比如漏洞没有检测出来，那或者说一些组件漏洞没有检测出来，或者说在内部的CI/CD融合过程中，可能我们之前没有想到融合的点，那么这种方式贡献到产品里面来，让整个产品的生命力和竞争力都可以变得更强。
开源之后我们收获了100家以上的企业客户。对于一些非开源的企业来说，作为单纯的乙方的安全公司，想去获得100个以上的客户的使用，这个成本是非常高的。
除了产品之外，对于商业来说，如果说有一个真正有需求的商业客户，尝试、购买这个流程会变得更短，整个运营的效率是非常高效的。
还有一点我们觉得现在的环境慢慢变好，大家在版权方面的法律问题，一定会得到比较好的解决，可能不会到达欧美的状态，所以我们也不太担心我们的产品会被拿去白嫖，即便有，如果说能够给我们一些比较好的反馈也是OK的。

我们在内部过程中，也遇到了非常多的挑战，举两个比较典型的问题和大家分享一下。
一个是发版的频次，我们最开始也觉得大家都走敏捷、走DevOps的路线，发版的品质非常的高。对客户来说，发版的频次特别高的情况下，他是不知道去用哪个版本的。这样客户就会比较奇怪，你这个版本发了之后，我到底要不要升，什么样的版本我应该升，什么样的版本我不应该升，我觉得这个是我们遇到的挑战，后面做了一些调整。
另外一个比较大的挑战，是客户支持上面的挑战。特别是面向To B的开源软件，特别是IAST这种产品，它是由上下游连接的一些场景，比如说IAST要跑在K8S里面，或者要去部署一个服务器，部署一个数据库进去，或者牵扯到多台机器里面，可能因为防火墙导致网络不通等等的一系列的问题，客户在遇到这些问题之后，都会找过来去做支持，有些只是社区里面的用户，或者可能是一些潜在的客户，通过开源的方式，虽然能够可能在短时间内拿到大批量的客户，但如果说这些客户遇到的问题都过来支持的话，其实是支持不了的，我们有一段时间是所有的研发同学都在做支持，基本上研发的工作都停了，那即便这样也是支持不过来的。
所以后面我们就搞了研发面对面的会议，让真的有关注度的用户提前准备问题，我们每周回答一下社区里面的问题，或者在github的issue里去做反馈和支持，大概的思路就是把一些能够标准化的问题，按照标准的流程去做，而不是去做一些非标准的实时响应，这个对整个团队的消耗是非常大的。

最后去聊一下商业化的事情，我们也是一家商业公司，所以做开源也会去有一些商业化的考虑，但整体来说，我们会在满足更多普通用户安全检测能力的基础上，去做商业化上面的一些尝试，常见的开源软件的商业化的方式大概分几类。
一类是开放核心服务、提供差异化的商业版本。最典型的像MySQL、MariaDB，大家再去使用MySQL或者MariaDB的时候，可能感觉不到商业化的，直接去用起来、去部署，好像稳定性也没有太大的问题，GitLab、洞态IAST大家直接用是没有太大问题的，但在背后也提供了一些商业化的，在功能上是有区别的，这些商业化的区分主要是针对一些大型的企业客户，比如说审计上面的功能，一些用户包括企业内部需要对接上面的一些诉求等等，像MySQL，专门提供了一个商业版的存储引擎，可以提供一些更高效的数据处理。
另外一类是商业变现的方式是提供服务托管，像MongoDB，公司除了提供标准的服务之外，可以减少运维的成本，直接用云的方式去托管整个服务，对客户来说在使用上就完全没有了任何运维的成本，甚至说一些扩容，这些都可以非常方便的去做。
但是对技术软件，比如说像数据库这种对数据非常敏感的客户来说，完全的托管服务是不太可行的，所以后面又衍生出了半托管的服务，半托管最典型的就是Databricks，你可以在Databricks界面上去关注、关联自己的AWS，去让数据去跑在自己的AWS上面，但是可以在Databricks这边去做管理和运维的操作。
另外PingCAP也是这种方式，用户部署的过程中，不太希望乙方公司直接接触到自己的数据，PingCAP会提供中间的机器，去方便外部的工程师进行运维，这也是半托管和全托管之间的一些区别。
我个人理解，半托管就是以非常低成本的方式，提供更好的运维的方式，不管是对甲方还是乙方来说都是更好的选择。

如果一款开源软件想去做商业化，它还需要有一些条件，大概列了一下。
第一个是用户的漏斗是否足够大，就是用户的数量是否足够大，如果说一款软件，他面临的客户数量是非常小众的，那么是可以做商业化的，但是通过开源的方式去做商业化的时候是会有问题，因为开源的这种方式没有办法很好的为商业化行为去做好的加持工作，因为你不需要去覆盖那么多用户，不需要那么多场景，因为用户数量就那么多。
另外一个判断标准是，是否有足够多的Feature来去支撑整个的商业化，因为开源之后，整个产品的Feature假如就100个，那可能自己的团队去开发60个，另外50个会随着时间的往后推移，如果产品还是有生命力的话，可能开源社区里面的贡献会把后面的几十个做掉，这时候整个在Feature上面去做产业化支撑，就会变得比较困难，也可以通过Feature数量来判断当前的产品是否值得做商业化，那如果不值得完全开源，所有的功能都通过一种更开放的方式来运作。
最后一点是商业化的Feature是如何做选择的，MySQL、MariaDB、洞态IAST最典型做的场景方式，是在针对企业级的需求去做选择，最典型的就是安全和审计。
另外一种策略像禅道、洞态IAST，会选择一些大客户的feature去做商业化的诉求，对于绝大部分的中小型厂商，开源版的Feature是足够满足日常的工作使用，比如说调用链，比如说非常实时的SCA商业的漏洞库的支持等等，像禅道他们的策略，针对项目管理的需求，真正的大客户或者说五十人、百人以上的需求会放在商业版里面，针对小的团队，基本上就是以100%支持的心态，去做能够支撑好小团队工作的一些Feature，这样整个产品是可以在商业化的前提下，得到一个非常好的软件的生命力。