前言

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

[[258573]]

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

今年，讓我們以擁有或依賴開源項目的創(chuàng)業(yè)公司作為開局。

Duality Technologies

創(chuàng)新沙盒也有賽道一說：密碼學(xué)自然是一條，每年都會出現(xiàn)一家入圍。在筆者看來，還要加上一條Team8：安全創(chuàng)業(yè)孵化器，班底是前以色列網(wǎng)絡(luò)安全部隊Unit 8200，每年必霸占一席。16年是Illusive，17年是Claroty，18年是Hysolate，今年便是Duality，拭目以待Portshift明年會不會出現(xiàn)。

Duality使安全的數(shù)據(jù)協(xié)作成為可能，企業(yè)可以將高級分析和AI應(yīng)用于加密數(shù)據(jù)，無需公開原始數(shù)據(jù)即可獲得對數(shù)據(jù)的洞察。沒有驚奇，技術(shù)方向是同態(tài)加密的應(yīng)用，17年入圍公司Enveil也是。Duality，對偶，公司名字真是妙手天成，恰到好處地融合了應(yīng)用場景與數(shù)學(xué)含義。

同態(tài)加密被正式廣泛研究已經(jīng)有十年歷史，現(xiàn)有算法都是基于格密碼(Lattice)理論的。Duality創(chuàng)始團隊有兩位大學(xué)教授，長期研究密碼學(xué)，創(chuàng)建了開源項目PALISADE，高度模塊化的通用格密碼實現(xiàn)庫，包含同態(tài)加密算法，有DARPA等政府機構(gòu)的資金支持。這是個價值極高的基礎(chǔ)設(shè)施級別的開源項目。題外話，Lattice-based算法是可以對抗量子計算機的，其實有很多加密算法在理論上也是安全的，并沒有一般科普文章寫得那么夸張;類似DH也可以用格密碼改造。

Duality的產(chǎn)品是個多方共用的中間平臺，官方設(shè)計了三種應(yīng)用場景。

數(shù)據(jù)所有者可在不公開敏感數(shù)據(jù)的前提下利用第三方分析和AI，此過程中數(shù)據(jù)受到端到端加密保護。還可在不受信任的云環(huán)境中操作。

分析模型所有者能安全地將其模型提供給數(shù)據(jù)所有者進行高級計算和分析，能確保其寶貴的AI算法模型產(chǎn)權(quán)在整個過程中得到完全保護。

多方安全協(xié)作處理敏感數(shù)據(jù)。同態(tài)加密在鏈接和計算過程中保護每一方的資產(chǎn)，確保數(shù)據(jù)隱私和整個過程的法規(guī)遵從性。

請注意，上述三種場景對于算法的要求是有區(qū)別的。在隱私和數(shù)據(jù)保護監(jiān)管收緊的大環(huán)境下，安全多方計算目前也是個大熱點。大部分讀者可能會以為保護數(shù)據(jù)隱私就夠了;而實際情況是，分析函數(shù)的秘密性也要保護，這也是數(shù)學(xué)家們努力的方向之一。

格密碼體制由于其運算具有線性特性，比RSA等經(jīng)典公鑰密碼體制具有更快的實現(xiàn)效率;又由于該類密碼體制安全性基于NP-Hard或NP-C問題，使其能進行量子防護。此外，格運算具有同態(tài)性，這也使格密碼算法能適用于各種同態(tài)加密的應(yīng)用場景。因此，有希望發(fā)展成下一代大范圍應(yīng)用的標(biāo)準(zhǔn)密碼庫。

密碼學(xué)是信息安全的重要基石。但在歷史上，除RSA成長為一家巨頭外，幾十年來專注加密的公司屢見不鮮，卻難有大作為。而Duality是一家安全行業(yè)極為少見的、對重要開源項目擁有話語權(quán)的創(chuàng)業(yè)公司，筆者抱有很高的期望。

開源項目的經(jīng)濟原理與商業(yè)模式

過去二十年的互聯(lián)網(wǎng)創(chuàng)新與開源項目息息相關(guān)。免費開發(fā)代碼且使用限制極少，聽起來美好到不像真實世界;因此，不少學(xué)者試圖用經(jīng)濟學(xué)原理解釋其背后的原因。自然也有不少投資者沖進來試圖分一杯羹，不過理想豐滿現(xiàn)實殘酷，出現(xiàn)了很多失敗案例。那么，創(chuàng)業(yè)公司和開源項目，應(yīng)該是什么樣的關(guān)系，才有成功機會呢?

如果我們仔細觀察RedHat這幾乎是巨頭成功案例，就會發(fā)現(xiàn)其除了大家熟知的開源許可外，還擁有大量商業(yè)授權(quán)許可。而這些商業(yè)許可所維護的，是眾多RedHat自研的核心代碼，這才是其龐大帝國的根基。因此，衡量創(chuàng)業(yè)公司價值，無論是開源還是閉源，歸根結(jié)底都會回到技術(shù)壁壘這一基礎(chǔ)問題上。

有些投資者看項目，嘴上說的是看技術(shù)水平，其實內(nèi)心深處對此不屑一顧，看的還是收入數(shù)字。聽起來沒問題啊，收入是不是衡量市場對技術(shù)認可程度的表現(xiàn)呢?賣開源發(fā)行版且銷售能力不錯的初創(chuàng)公司是不是值得競相追逐呢?

這背后的邏輯值得商榷。首先，在今天，服務(wù)的壁壘已經(jīng)不能僅靠人員團隊了，信息咨詢服務(wù)巨頭Accenture也擁有很多代碼和系統(tǒng)的積累，正如RedHat依賴其自有知識產(chǎn)權(quán)模塊一樣。安全行業(yè)里的MSSP也是如此：如果想提供SOC服務(wù)，自己沒有一套先進的運營平臺系統(tǒng)，是沒有任何競爭能力的。其次，對開源項目的代碼維護審批沒有話語權(quán)的，那并不是產(chǎn)品公司，那是集成商;應(yīng)該按集成商的商業(yè)模式衡量其估值。原因很簡單，技術(shù)壁壘才有溢價，包裝發(fā)行版無法獲得溢價。第三，全球范圍內(nèi)，已經(jīng)出現(xiàn)多起開源項目運營公司增加商業(yè)使用限制的許可條款的案例，這對賣開源發(fā)行版的業(yè)務(wù)模式絕對是當(dāng)頭重擊。大部分開源項目是基礎(chǔ)通用型的，需要找到合適應(yīng)用場景才能大規(guī)模商業(yè)化。

而Duality正是一家滿足上述邏輯的開源項目創(chuàng)業(yè)公司，筆者也希望其能挖掘在密碼領(lǐng)域和行業(yè)應(yīng)用的發(fā)展?jié)摿?，做大做強。下面我們再來看看其它有開源項目的入圍者。

Capsule8

Capsule8是業(yè)界專為Linux生產(chǎn)系統(tǒng)構(gòu)建的實時零日漏洞檢測平臺，無論是容器、虛擬機、還是裸物理機。官方宣傳口徑。你信嗎?反正我是直接忽略。國內(nèi)就好多做的，更甭提全球范圍。創(chuàng)始人John Viega履歷光彩奪目，業(yè)界資深專家，團隊也有不少著名黑客。

主機防護，相信大部分讀者都很熟悉，筆者此處就不過多介紹了，撿些Capsule8特有的講講。其產(chǎn)品平臺強調(diào)的能力包括：可見、檢測、調(diào)查、瓦解、集成，花了濃重筆墨渲染自動化防護。

Capsule8的開源sensor用Go寫成，基于Kprobes，使用gRPC。筆者的反應(yīng)，看起來是Google派系的。果然，稍后就翻看到官方視頻專門演示與Google云管理界面集成，技術(shù)路線就決定其它云沒那么容易集成了。當(dāng)然，用Capsule8自身管理界面也可以支持AWS和Azure。多云也是有技術(shù)壁壘要克服的。

技術(shù)路線選擇很費腦力，也必須認真，否則會導(dǎo)致事倍功半。Capsule8初創(chuàng)時的戰(zhàn)略瞄準(zhǔn)容器，自然Go是較好的選擇，因為容器世界底層是Go語言的天下。生產(chǎn)環(huán)境中性能十分重要，雖然Go性能比不上C，尤其是Regex處理速度差距較大，而Kprobes開銷也不小;但考慮到兼容穩(wěn)定與未來擴展，如此選擇還是蠻有道理的。

選擇部署哪個開源agent這事兒也兩難。Capsule8的sensor是輕，只采集跟安全相關(guān)的數(shù)據(jù)，主要有FileEvent、KernelFunctionCallEvent、NetworkEvent、PerformanceEvent、ProcessEvent、SyscallEvent、UserFunctionCallEvent、ContainerEvent等;部署一個agent只做0-day檢測感覺性價比不高。不過，osquery在內(nèi)核調(diào)用檢測方面是短板，目前只支持auditd，Kprobes和eBPF的支持還在開發(fā)中，不知道要等到啥時候。甲方同學(xué)需要自己權(quán)衡。

采集主機數(shù)據(jù)之后，還要看看管理端是如何進行數(shù)據(jù)分析以實現(xiàn)檢測的。

說實話，成立兩年多的公司，這管理界面有些寒酸。大規(guī)模部署，看報警恐怕會瘋掉。有查詢界面也是題中應(yīng)有之義，新產(chǎn)品需要支持威脅獵捕Threat Hunting。筆者最關(guān)心的檢測技術(shù)說明，居然找了半天找不到。不提機器學(xué)習(xí)，不提行為分析，不提Yara，不提數(shù)據(jù)分析，總不會報警全靠人看吧。比賽上臺面對評委時，難道也要回避這塊關(guān)鍵技術(shù)能力不說?就看到演示界面里一堆Interactive Shell Executed了，貌似是基于一些預(yù)先定義的規(guī)則，不知道如何更新。

看過演示再對比這張安全運營能力圖，結(jié)論是產(chǎn)品團隊未來要走的路還很長。如此看來，Capsule8的開源項目也沒多高價值。筆者只能去RSAC展臺現(xiàn)場看看產(chǎn)品新版本做到什么程度。

Capsule8的投資者是美國兩個頻繁出手安全領(lǐng)域的VC：ClearSky和Bessemer (BVP)。有趣的是，他們與創(chuàng)新沙盒結(jié)緣頗深，在其投資名單上可以看到很多熟悉的公司，如這幾年的Axonius、BigID、Claroty、CloudKnox、CyberGRX、Hysolate。

ShiftLeft

ShiftLeft是應(yīng)用安全的持續(xù)改進平臺，于自動化工作流中，將下一代靜態(tài)代碼分析(以快速準(zhǔn)確地識別漏洞)與應(yīng)用插樁檢測(以保護生產(chǎn)環(huán)境應(yīng)用)結(jié)合在一起。這種“理解運行狀態(tài)的代碼分析”和“理解代碼的運行時保護”的結(jié)合提供了精確、自動化、和覆蓋全面的應(yīng)用安全解決方案。組合方案，前者是SAST，還有些許SCA，后者是部署在生產(chǎn)的IAST、以及RASP的混合體。官方宣傳后者確實有些新意，能加快DevOps的速度。工作流如下圖所示：

公司名起得也不錯。Shift Left Testing，左移測試，是軟件領(lǐng)域歷史悠久的概念。這名詞也讓筆者回憶起小時候在單片機上撥動二進制開關(guān)輸入左移位運算指令的操作。左移的含義，跟現(xiàn)在業(yè)內(nèi)宣傳的安全規(guī)劃前移至應(yīng)用系統(tǒng)架構(gòu)設(shè)計階段是類似的。將關(guān)鍵測試實踐前移到SDLC早期階段，尤其適用于敏捷開發(fā)、持續(xù)迭代、和DevOps場景。傳統(tǒng)上，測試活動多發(fā)生在研發(fā)后期，往往需要更長時間才能找出問題所在，并且需要花費更多的時間來修復(fù)。左移是指將代碼缺陷的識別和預(yù)防轉(zhuǎn)移到更早的階段，否則如果后期測試出問題，往往能做的就只是修補，而非正確的修復(fù)。

應(yīng)用安全是行業(yè)持久熱點，新方向新技術(shù)層出不窮。ShiftLeft吸引人的產(chǎn)品創(chuàng)新有兩處，一是在靜態(tài)代碼分析時引入圖算法，比之前傳統(tǒng)代碼檢測算法能更好地發(fā)現(xiàn)某些類別的漏洞;二是在靜態(tài)分析階段引入所謂安全DNA概念，用于指導(dǎo)生產(chǎn)環(huán)境中的IAST和RASP的執(zhí)行。

首先，SAST的創(chuàng)新來自于學(xué)校研究，基于代碼屬性圖CDG的漏洞發(fā)現(xiàn)，論文如下。

此研究成果誕生了開源項目Joern，可以掃描Java和C/C++代碼，并生成三類屬性圖：抽象語法樹、控制流、和數(shù)據(jù)流。再使用圖算法用自定義查詢就能發(fā)現(xiàn)潛在漏洞。值得吹噓的戰(zhàn)績，一次性發(fā)現(xiàn)Linux kernel里的18個新漏洞。顯然是高價值的開源項目，吸引了很多眼球。ShiftLeft成立后，Joern得到繼續(xù)發(fā)展，現(xiàn)在的產(chǎn)品名稱為Ocular。官方稱目前OWASP基準(zhǔn)測試成績較好。當(dāng)然，沒有銀彈，圖算法也不能通吃所有類型漏洞。下圖展示了如何用CDG發(fā)現(xiàn)代碼中潛在數(shù)據(jù)泄漏的弱點，很有趣的思路。

而所謂安全DNA，是指容易出現(xiàn)弱點的代碼位置，例如引入第三方開源庫、模塊間傳遞參數(shù)、敏感數(shù)據(jù)使用等等。所謂MicroAgent，實質(zhì)就是程序插樁，保證程序原有邏輯完整性的基礎(chǔ)上，插入一些探針進行信息采集，還可以根據(jù)預(yù)定義策略做些簡單響應(yīng)。有了開發(fā)階段靜態(tài)分析產(chǎn)生的安全DNA信息，插樁可以更有的放矢，檢測效率更高，降低誤報。通常，快速開發(fā)迭代過程中，時間不夠用來修復(fù)所有潛在問題，必須有所取舍;而未修補之處是否存在風(fēng)險，可以放到生產(chǎn)環(huán)境繼續(xù)監(jiān)控。此種方式也加快了DevOps進程。

之后，將這些報警傳回控制臺，再用來反哺開發(fā)代碼階段，于是便覆蓋大部分SDLC和DevOps流程。

延伸思考，Joern自然也可以用于紅隊。上面提到過，CDG可以繪制數(shù)據(jù)流，那么自然而然地我們會想到，合法數(shù)據(jù)輸入可作為暴露在外，如果能梳理此輸入數(shù)據(jù)在程序中被處理的代碼段有哪些，我們就可以有針對性地檢查，那些代碼段中是否存在沒做好“消毒”的地方，例如內(nèi)存越界。Heartbleed漏洞即屬于此類型。如果沒有數(shù)據(jù)流圖，在龐大代碼量中，準(zhǔn)確定位并發(fā)現(xiàn)潛在風(fēng)險，只能靠運氣了。

這個實例說明，只有掌握了新的技術(shù)，才能在對抗中獲取有利位置。再優(yōu)秀的安全團隊，沒有先進工具的武裝，戰(zhàn)斗力都會大打折扣。

篇幅所限，筆者就不深入解釋了。目前看產(chǎn)品完成度較高，在創(chuàng)業(yè)公司里算出類拔萃的。與其兩輪大額融資也有關(guān)，畢竟錢多更容易擴大團隊完成更多工作。

上面講到的三家擁有開源項目的入圍者，讀者更喜歡哪個?

不知道大家有沒有注意到，ShiftLeft也符合筆者前面所講的開源商業(yè)模式。以開源Joern為基礎(chǔ)，識別巨大市場需求，補充整合優(yōu)秀人才，繼續(xù)開發(fā)更先進的技術(shù)模塊，組合成更復(fù)雜的產(chǎn)品，建立競爭壁壘。成熟完整的管理團隊，從開源項目中發(fā)現(xiàn)潛力新秀，用股份相邀所有者亦即學(xué)院派研究人員，強強攜手，再造商業(yè)公司，如此套路在今天已經(jīng)屢見不鮮。Duality也是相同軌跡。

如果哪位讀者對自有研究成果信心十足，歡迎找筆者聊聊。我們在采用先進技術(shù)打造全球領(lǐng)先產(chǎn)品并服務(wù)好各行業(yè)頭部用戶這方面，積累了不少成功經(jīng)驗。

DisruptOps

DisruptOps為多云基礎(chǔ)設(shè)施提供持續(xù)自動化監(jiān)控的優(yōu)秀安全實踐，以提升云業(yè)務(wù)運營的安全性并降低成本。讀者也許已經(jīng)在朋友圈看過此公司的介紹文章，都是唬人的名詞：多云、自動化、敏捷、編排、DevSecOps、持續(xù)評估、優(yōu)秀實踐、云原生等等，還發(fā)明了Guardrail護欄一詞的新用法。

多云管理市場的商業(yè)機會與重要性，筆者在去年創(chuàng)新沙盒文章就強調(diào)過。然而，DisruptOps你是在逗我嘛?翻遍其網(wǎng)站，所有能力都是針對AWS的，說好的多云呢?筆者開始時還不相信自己，以為漏掉重要內(nèi)容，于是專門用了搜索引擎：

未見任何Azure蹤影，確實只有AWS。目測DisruptOps平臺主要使用AWS原生安全產(chǎn)品的API來構(gòu)造，如Config、CloudWatch等;Serverless架構(gòu)，大量使用Lambda腳本。若打算將界面設(shè)計和產(chǎn)品功能，原封不動從AWS移植到Azure，難度不小，工作量巨大。正如上面評論Capsule8時所指出，多云也是有技術(shù)壁壘要克服的。

DisruptOps創(chuàng)始團隊包括安全咨詢公司Securosis核心班底，歷來產(chǎn)出的研究和文章質(zhì)量很高，筆者進入安全行業(yè)之初便拜讀過?？上攵?，他們深諳使用專有名詞忽悠客戶之道。我們看到國外初創(chuàng)公司也不容易，吹噓是為了生存。DisruptOps成立于2014年，時間不短了。當(dāng)然，也是因為DisruptOps客戶群體看不到本文，所以筆者才會如此直接落筆。

說實話，筆者瀏覽此公司網(wǎng)站之后的反應(yīng)：這不是個產(chǎn)品公司，羅列的都是內(nèi)部安全運營規(guī)范。優(yōu)秀實踐美則美矣，但如此定位的商業(yè)模式，能否持續(xù)增長是個大大的問號。讀者們肯定見過各大廠自建開源的GitHub內(nèi)容掃描工具，但業(yè)內(nèi)見過廠商推出類似的標(biāo)準(zhǔn)化產(chǎn)品嗎?做安全產(chǎn)品要有足夠的能力護城河，才能維護市場競爭優(yōu)勢，靠些零散拼湊的配置核查腳本集合，就能建立壁壘嗎?需求并不一定等于生意。

什么產(chǎn)品能力可以做護城河?舉個簡單例子。文件格式解析引擎，用于拆解并導(dǎo)出各種格式文檔中的文本圖片等內(nèi)容。迄今，全球成熟商業(yè)化供應(yīng)商只有兩家，一家是MicroFocus的KeyView(之前歸屬于Autonomy和HP)，另一家是思睿嘉得。KeyView不支持導(dǎo)出DWG等CAD圖紙中的文本，而后者的引擎可以;KeyView不支持百度網(wǎng)盤大文件分卷上傳的還原，而后者可以;等等。全球絕大部分DLP廠商都是外購引擎，從而受制于供應(yīng)商的緩慢更新延遲;而思睿嘉得掌握全部自研代碼，擁有更低的成本、更優(yōu)秀的性能實現(xiàn)、更靈活的接口控制、以及對最終用戶需求的快速響應(yīng)。唯有多個類似的、友商難以復(fù)制的技術(shù)能力，再加以堆疊組合，才能有效鞏固產(chǎn)品優(yōu)勢。

定期更改訪問密鑰AK是一種眾所周知的安全實踐?？s短AK有效時間，即使泄露，業(yè)務(wù)受到的不利影響也能被緩解。DevSecOps的實施難點，是如何定期生成新AK并準(zhǔn)確分發(fā)，令使用對應(yīng)舊AK的所有應(yīng)用程序自動更新，保證交接順暢，不會造成任何故障。而DisruptOps產(chǎn)品確實能發(fā)現(xiàn)老舊的AK，但之后提供行動的選擇只有區(qū)區(qū)四個：刪除、凍結(jié)、掛起等著手工操作、以及忽視。這怎么嵌入到DevOps流程里?隔靴搔癢的雞肋，到底是用還是不用?另一方面，Access key age屬性，可以直接去Console查，或者寫Lambda腳本集成到自有DevSecOps平臺里也易如反掌，讓大甲方花錢買這個短板明顯的功能有難度，而小企業(yè)有沒有人手跟隨優(yōu)秀實踐也難說，還面臨著云服務(wù)商不遠將來也提供類似功能的競爭，例如AWS Inspector或GuardDuty加入此類報警輕而易舉。

總體來看，產(chǎn)品成熟度很低，過于簡單，只提供初級安全基線檢測，且未見靈活配置和擴展功能。概念不錯，落地差得太遠，技術(shù)門檻低，甲方評估后恐怕會得出采購不如自研的結(jié)論。從另一個角度看，DisruptOps倒是提供了一組基礎(chǔ)安全范本，云安全團隊初建時可以拿來作為起步參照。