安全軟件如何做開源

今天給大家分享的內容分為三個部分

第一個是安全行業，開源產品的簡單概況，包括國外的開源產品以及國內整個安全行業的開源和國外有什么不一樣。

第二個是洞態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，這樣整個產品是可以在商業化的前提下，得到一個非常好的軟件的生命力。

最后補充一下洞態IAST的相關資料：

洞態IAST官網：https://dongtai.io

洞態IAST演示站點：https://demo.iast.io

洞態IAST項目倉庫地址：

https://github.com/HXSecurity/DongTai

洞態IAST相關使用文檔地址：

http://docs.dongtai.io/