從RSA創新沙盒決賽產品ShiftLeft淺談DevSecOps
責編：gltian ｜2019-02-26 15:35:54一、背景
RSA大會將于3月4日在美國舊金山開幕，RSA創新沙盒決賽十強產品都是網絡安全領域的創新者，同時也從一定程度上代表著國際網絡安全各個細分領域的火爆程度。
從今年的十強產品看，數據安全、云計算安全連續多年上榜，持續火熱，業務安全和DevSecOps嶄露頭角，這也意味著未來1-3年的安全創新方向。
十強產品中ShiftLeft聚焦于DevSecOps，DevSecOps雖說各有各的玩法，暫未形成大家公認的標準，但是基本上都是SAST,DAST等產品，當然也包括最近火起來的IAST和RASP，接下來一起看看ShiftLeft，聊聊DevSecOps。
二、ShiftLeft為何能進決賽
ShiftLeft有三款產品Inspect、Protect、Ocular。
ShiftLeft的主打產品無疑是ShiftLeft inspect，一款漏洞檢測產品，inspect將SAST和IAST融合到一個產品里，跟DevOps工具鏈進行集成，作為上線前的漏洞檢測方案。
2.1 SAST部分
傳統的SAST類產品作為編碼階段的安全工具，其實很多國外知名的白盒廠商都為它們的產品配備了集成Jenkins和Gitlab的手段，但是在DevSecOps中一般難以有特別好的效果，主要受限于SAST類產品的誤報率和檢測時長。DevOps中很重要的一點就是“天下武功，唯快不破”，強調一體化，自動化與速度，Jenkins、Gitlab等DevOps工具鏈的集成從一定程度上解決了一體化和自動化的問題，但是問題終回歸到SAST類產品的核心競爭力：檢出率、誤報率、檢測速度上，這些決定了安全活動的周期，也決定DevSecOps能否很好的執行和落地。
我們先看看OWASP對SAST和DAST類產品在OWASP Benchmark的測試結果：
SAST類產品可以做到檢出率高達85%，但同時誤報率也有52%，誤報也就意味著需要介入人工核查，而且眾所周知，代碼審計工作所需要的周期偏長，特別是從數百數千個漏洞中，找出誤報，意味著每個漏洞都要審查，會極大的拖慢DevOps周期。那如果說開發同學不管是否誤報全部修復，這樣是否可行呢？這就牽扯到開發人員與安全人員配合的問題，本身可能大部分開發人員對安全工作存在少部分的抵觸心理，認為是工作量的增加，如果修復方案簡單還好說，如果某個漏洞的修復比較復雜，又被發現是誤報，可能開發與安全的信任關系斷裂，不利于后續安全工作的開展。
那ShiftLeft是如何解決上述難題的呢？答案是：強行解決！
先看ShiftLeft 自己發布的ShiftLeft inspect在OWASP Benchmark的測試結果：
檢出率100%，誤報率25%，最終得分75，幾乎是第二名的兩倍。（當然，結果是ShiftLeft自己發布的，也可能針對OWASP Benchmark做過特殊優化），這個得分可以很大程度上可以解決SAST在DevSecOps中難以應用的問題。
再談到速度，用過白盒產品的同學應該都知道，傳統SAST類產品檢測速度偏慢，收到過客戶的真實反饋，100w行代碼足足檢測了10個小時，這個時間在DevOps中是難以忍受的。ShiftLeft inspect根據官網放出的數據，50w行代碼檢測時間10分鐘。有這兩項優勢，決定了ShiftLeft inspect的SAST模塊在DevSecOps中足以站住腳。
ShiftLeft inspect是如何做的呢？這個涉及到SAST類產品的技術底層，ShiftLeft也很聰明，放數據別人可能覺得它在吹牛，所以也深淺有度的介紹了下用的底層原理，這里也給大家簡單介紹下，這要從自動化代碼審計的技術實踐說起。
安全產品要做到獨一無二，筆者認為粗略可分為兩種壁壘：技術壁壘和客戶壁壘，技術壁壘即使技術難度，技術創新和最終效果，客戶壁壘從產品層來講即是對客戶需求的滿足度，包括是否滿足行業、客戶的特點等。SAST類產品的技術門檻，在筆者看來應該是SAST、DAST、IAST中最高的，做好了擁有較高的技術壁壘，所以這也是為什么知名廠商的白盒產品貴的嚇人，客戶還不得不買。
很多沒研究過白盒工具的同學對自動化代碼審計的印象可能僅存在于采用正則匹配的方法，這是最好理解的，也是效果最差的，SAST類工具的技術實踐大致可分為以下幾種：
（1） 正則匹配：代表工具cobra，raptor；
（2） 基于語法樹:代表工具p3c,fireline；
（3） java語言可基于class文件:代表工具findsecbugs；
（4） 基于控制流、數據流、函數調用關系等:市面上的商業級SAST類產品。
當然，效果是逐漸遞增的，難度也是逐漸增大的，篇幅有限，這里簡單介紹基于控制流和數據流的商業級產品的大致技術思路。
要實現還原代碼的數據流、控制流和函數調用關系，需要將編譯中的前端模塊完全實現一遍，基于中間代碼去還原數據流和控制流等，大致流程如下：
每個階段的具體實現大家可自行查看編譯原理相關的知識，這里不展開講，其中詞法分析和語法分析一般可以借鑒相應的開源工具可以完成，但是語義分析依賴于各種語言的語法，針對每種語言一般需要單獨實現，不同的語言翻譯成同一套規范的中間代碼，根據翻譯來的中間代碼，符號表等來恢復數據流、控制流和函數調用關系等，然后根據這些流來確定污點傳播過程，進而確認是否存在漏洞。
白盒類產品誤報率高和耗時長的原因也跟這個復雜流程相關，各個安全廠商自己基于編譯原理相關內容實現的代碼分析模塊，還原的數據流、控制流等難以做到100%準確，同時對100w行這種大量的代碼分析，資源占用大，復雜度較高，數據流、控制流的構建過程自然就耗時長，導致了SAST類產品誤報率高和耗時長這兩個問題難以解決。
回到正題，ShiftLeft是如何解決這個問題？ShiftLeft inspect一直在強調CPG（代碼屬性圖）這個概念。
CPG可以看做豐富版的AST（抽象語法樹），利用了一個基于island grammar的，直接從源碼抽取AST的分析器，抽取AST可以只做到語法分析步驟，執行速度很快，而通常耗時的部分是在中間代碼和數據流、控制流還原等，然后對AST做針對漏洞檢測所需特征的自定義優化來生成CPG，然后基于CPG去做漏洞檢測。單純的基于AST檢測能力有限，關鍵點在于從AST到CPG的過程，決定了最終漏洞的檢測效果，當然，ShiftLeft也沒說,下圖是CPG分析某段代碼出來的結果：
基于CPG檢測漏洞在可視化方面，除了調用過程，還可以展示出代碼層次深度結構，ShiftLeft把可視化也做到不錯，用3D展示出來。
ShiftLeft還專門為CPG的生成做了一個工具，ShiftLeft Ocular 一個命令行生成CPG的工具，用于代碼查找，漏洞排查等等。
2.2 IAST部分
IAST是最近比較火的一個概念，IAST有著一些明顯的優勢，比如：近實時檢測、誤報率極低、可定位到代碼行數、展示污點調用過程等等，非常適用于DevSecOps流程，ShiftLeft inspect中也包含了IAST部分。
其中的Microagent即是做IAST漏洞檢測的模塊，當然，ShiftLeft換了個名字，叫做SPR（運行時安全檢測），本質上是一樣的。
IAST其實還比較難做出差異性，都知道它的優點，產品中也會盡力體現污點調用過程，代碼行數等不同于DAST的，偏代碼層的信息，ShiftLeft inspect不僅僅有這些，而且看清楚了現在的安全熱點，特地在數據安全部分下了功夫。
用NLP和ML相關的技術，通過IAST獲取的數據傳輸流，執行點等，辨別哪些是敏感數據，對于敏感數據的一些打印、輸出等操作進行告警，這個點比較有新意。
2.3 RASP模塊
ShiftLeft protect是一款RASP類產品，一般做IAST的廠商都會做RASP，因為技術底層都差不多，稍微改一改就是另一個產品，ShiftLeft protect同樣也把數據泄露的告警作為一個重要功能。
有些廠商在宣傳中把RASP跟WAF對比，筆者認為這是比較不明智的，WAF發展到現在，在機器學習的加持下，誤報率，檢測率，對業務的影響度已經做的非常優秀，RASP雖然效果也不錯，但對業務的影響個人認為要高于WAF。
ShiftLeft protect是怎么宣傳RASP的呢？眾所周知，很多企業在上線前進行漏洞檢測，都要求解決高中危漏洞，在業務緊急上線的情況下，低危漏洞往往可以選擇性的忽略，一般會經過評審，各個負責人簽字等流程，DevSecOps因為強調速度，這種情況則更多，但是作為一個安全人員或者項目經理，忽略這些低危漏洞真的放心嗎？攻擊者可能不會通過這些低危漏洞來直接攻擊業務，但是往往成為攻擊鏈中的一環，獲取某些敏感信息等，那RASP的作用就是在Ops階段，繼續針對性的保護那些被忽略的低危漏洞。
ShiftLeft protect對RASP在DevSecOps中的定義切中要害，而且跟DevSecOps十分契合！
綜上，ShiftLeft入選RSA創新沙盒10強是在產品核心產品競爭力不輸競品的情況下，將SAST、IAST、RASP集成到DevOps工具鏈中，解決了SAST產品的痛點，創新的加入數據泄露檢測，形成編碼，測試，運行階段的產品解決方案，得以入選RSA創新沙盒10強。
筆者所在的安全廠商默安科技，也在DevSecOps方面做了諸多努力和實踐，其自主研發的靂鑒軟件開發全流程安全框架的很多理念跟ShiftLeft不謀而合，通過SAST、IAST、DAST類產品與GIT、SVN、Jenkins等DevOps工具鏈集成，覆蓋編碼，測試，運維階段，幫助客戶形成完整的DevSecOps解決方案。