前言

前段時間微信群里有朋友說起，今年RSAC創新沙盒入圍的企業，感覺毫無新意和亮點，平淡無奇;緊接著另一個朋友有感而發，說及最近看到的分析師文章，總覺得炒冷飯和嘩眾取寵成分居多，也十分平庸;于是大家都紛紛聊起來，安全行業近兩年創新不夠。很有道理的觀察，筆者完全同意。不過要補充一點：不是因為別人變矮，而是因為我們的眼界變高：過去四年，筆者親眼目睹了國內安全技術的飛速發展，在某些領域，國內先進水平廠商至少能跟創新沙盒入圍者相提并論，甚至還有明顯勝出。即使國內行業大生態對創新并不友好，天量預算被巨頭把持，去年業界增長也令人失望，但革新與開拓并未被遏制，無論是大廠或是初創小公司均有耀眼貢獻。

[[258573]]

于是，創新沙盒評論便愈發難寫，介紹入圍者的文章多到汗牛充棟，讀者并不感冒淺嘗即止的內容，堆砌華麗詞藻更會被嗤之以鼻，筆者亟需找到一些獨特的角度才能滿足眼界變高的讀者們的胃口。如果我們能拋棄吹捧，透過花哨探究本質，試圖不放過產品和業務的弱點，對提高自己獨立思考的能力便有莫大好處。

今年，讓我們以擁有或依賴開源項目的創業公司作為開局。

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倒是提供了一組基礎安全范本，云安全團隊初建時可以拿來作為起步參照。