從2020RSA創新沙盒看開發安全產品方向

安全牛 發佈 2020-02-24T02:42:50+00:00

代表著安全產品創新方向的「創新沙盒大賽」十強廠商中,半數是做應用安全類產品的廠商,包括做應用安全測試的BluBracket、ForAllSecure,做應用安全防護的Sqreen、TaleSecurity,以及做漏洞管理的Vulcan Cyber,這從一定程度上反映出應用安全在安

2020年RSA Conference將於2月24日在舊金山拉開帷幕,今年大會的主題是「HUMAN ELEMENT」。代表著安全產品創新方向的「創新沙盒大賽」十強廠商中,半數是做應用安全類產品的廠商,包括做應用安全測試的BluBracket、ForAllSecure,做應用安全防護的Sqreen、Tale Security,以及做漏洞管理的Vulcan Cyber,這從一定程度上反映出應用安全在安全市場上的火熱程度,也指引了應用安全領域的創新方向。與開發安全相關的廠商是BluBracket和ForAllSecure,他們的產品都宣稱能夠更好地幫助企業落地DevSecOps,下面我們一起來看看這兩款產品。

代碼安全:BluBracket

BluBracket是一家專注代碼安全的廠家,並宣稱是其方案是第一個完整的企業代碼安全解決方案。它向用戶傳達的焦慮是「你的代碼無處不在」,由於雲和GIT等代碼倉庫的流行,企業的代碼可能分布在各個地方,「代碼在哪兒?誰能訪問?代碼中有哪些信息?」是BluBracket當前致力於解決的問題。

與CheckMarx、Fortify等傳統原始碼安全大廠不同的是,BluBracket幾乎不涉及原始碼的漏洞檢測,更偏向於代碼的安全管理、代碼中的敏感信息泄露與開源組件風險。

這是一個初創公司比較聰明的做法,因為原始碼的漏洞檢測技術門檻太高,創業公司不太可能在短時間內形成競爭力,所以漏洞檢測這部分只做敏感信息泄露和開源組件風險是非常正確的選擇;同時原始碼的安全管理其實往往是企業忽略的點,算是開發安全管控中比較新的方向,比如最近兩年企業都比較重視的GitHub代碼泄露,就屬於這個方向,BluBracket把代碼泄露和管控不當這類問題成體系地給出解決方案。

BluBracket的解決方案分成四步:發現和分類代碼→監控代碼風險→保護有價值的代碼→實施安全策略。

BluBracket套件中有兩個產品:CodeSecure和CodeInsight,CodeInsight主要負責對代碼進行發現、分類、持續跟蹤以及開源庫的檢測;CodeSecure主要負責對代碼進行敏感信息泄露檢測、訪問控制、主動發現、策略定義、開源庫安全檢查等;從官網給出的產品介面可以看出產品功能基本與上述宣傳相符,能夠幫助企業發現代碼位置、倉庫類型、倉庫操作記錄、敏感信息泄露檢查等。

BluBracket在其DevSecOps方案中主要強調了3點:

整體來看BluBracket的方向比較新穎,也確實是企業目前普遍忽視的點。隨著企業應用安全的水位逐漸上升,對代碼安全管控的重要性也會逐漸體現出來。

但是有兩點值得關注一下。一個是代碼安全管控什麼時候會從「普遍忽視」變為「普遍重視」。BluBracket本質上解決的是代碼泄露所帶來的安全問題,不管是內部泄露還是外部泄露,企業本身在安全建設中多多少少會覆蓋到代碼的安全控制,比如員工行為管理系統,涉及到對敏感文件的操作審計和控制;有些DLP方案將代碼視為敏感數據的一種,從而進行管控等等,這類問題恐怕更像是事件驅動型,只有具體事件發生後才會專門為代碼安全管控規劃一套方案,以及用戶POC測試的時候未必會真的發現代碼泄露問題,所以在當下該如何去說服客戶以及如何體現產品效果值得思考。

第二點是從整體的產品介紹中,從我個人角度看並沒有發現產品擁有很高的技術壁壘,更多的是第三方集成、適配、策略收集的工作,所宣傳的基於ML和AI進行代碼的自動分類分級在整體安全能力上看其實價值有限,如果僅僅依靠方案比較全面來作為競爭力,會有較大的被替換風險。

模糊測試:ForAllSecure

ForAllSecure的主打產品是Mayhem,宣稱是下一代模糊測試解決方案,融合代碼覆蓋引導和符號執行的動態分析技術,能夠做到更高的程序覆蓋度和漏洞發現率,並且做到零誤報。

隨著IoT業務的大爆發,C/C++也重回GitHub的流行榜首,對於二進位文件的黑盒安全測試幾乎只能用模糊測試的方法進行覆蓋。只不過由於技術門檻比較高,在很多開發安全廠商的方案里沒有涉及到。模糊測試一直是開發安全方案里的一塊業務,比如Synopsys的開發安全方案里就包含專門進行模糊測試的工具Defensics,用於覆蓋二進位和協議方面的黑盒安全測試。隨著物聯網的持續火熱,模糊測試在安全開發領域的重要性會逐漸增強。

ForAllSecure在產品方案層面上,通過對比SAST的高誤報、SCA發現的是已知風險、DAST只能通過已知攻擊手法去擬合,從而突出fuzzing對0day未知風險的發現覆蓋能力。

在技術層面上,ForAllSecure專門出了一份Benchmark測試報告,對比Mayhem與其他Fuzzing工具的優勢,主要體現在更高的代碼覆蓋度、更快的檢測速度和更少的測試用例三個方面。

ForAllSecure在語言方面支持C/C++和golang,後續會對java語言支持;第三方集成方面支持與Travis CI、Jenkins CI/CD平台集成,GitLab和GitHub代碼倉庫集成;平台支持Linux、ARM和X86,後續會對Windows進行支持。

在DevSecOps方案上,ForAllSecure根據DevOps的流程執行五種安全檢查,在Build階段進行組件安全測試,在測試驗證階段進行威脅建模、動態測試和異常測試,在部署階段進行回歸測試。

與DevSecOps的流程整合上,官方資料描述比較簡單,通過與CI/CD pipeline集成,在Build之後自動化上傳可執行程序到Mayhem平台上進行安全測試,再將測試結果輸出到BUG管理平台或同步到CI/CD平台上;同時也支持用戶手動上傳二進位文件進行安全測試。

綜上來看,ForAllSecure從12年成立到現在,持續沉澱了多年的Fuzzing技術,在技術壁壘上是有一定競爭力的。隨著物聯網的火熱,業務和市場也會越來越大。

但需要注意的問題是,當前開源的Fuzzing平台也有很多,尤其以Google的ClusterFuzz最為著名,從ClusterFuzz所用的LibFuzzer、AFL的代碼覆蓋引導技術和已經發現的漏洞成果上來看,都屬於很高的水平。如何向客戶闡述商業工具與開源工具之間的差別是關鍵點,如果僅僅從技術的角度說明差別,對於較高級別的客戶是枯燥無味的,也難以打動用戶,檢測效果上細微的差別一定不是用戶最關心的點,更需要從用戶在日常DevSecOps活動中的問題和痛點出發,在這部分的價值上ForAllSecure的官方資料較少。

本次RSA創新沙盒所選出的兩家開發安全廠商,他們所做的產品與我們普遍認知的開發安全產品體系(SAST、SCA、IAST、DAST)有著明顯的差異,屬於比較創新的產品方向——代碼安全管控和模糊測試,給了我們新的思考與啟發。

在物聯網、雲、容器不再是趨勢而已經廣泛應用的當下,在未來Serverless或許真正盛行的時候,開發安全應該要做出什麼樣的變化去順應IT的發展?大廠的技術壁壘可能因為某些開發模式的更改而逐漸降低,比如傳統DAST的衰弱,新興的IAST與SCA的流行,再比如無服務架構FaaS對開發安全產品要求的巨大變化。每個廠商都有機會重新定義開發安全的標準模式和產品體系,是創新者向市場領導者發起挑戰的機會,當然這背後離不開對技術、業務、用戶以及IT發展的深度思考,更離不開仰望天空、腳踏實地的一群創新者。

關鍵字: