<bdo id="2b3yk"><code id="2b3yk"></code></bdo>

  • <output id="2b3yk"><sup id="2b3yk"></sup></output>
    <output id="2b3yk"><ruby id="2b3yk"></ruby></output>
  • <code id="2b3yk"><delect id="2b3yk"></delect></code>

  • 百度《企業級自動化代碼安全掃描實戰》讀后感

    近日百度安全應急響應中心發布了《企業級自動化代碼安全掃描實戰》,讀者可以管中窺豹,實例了解靜態代碼分析在互聯網公司的落地情況,了解該領域的業界的技術趨勢和進展,查漏補缺發現企業內部建設不足,對標評估自研安全能力,立足自有工具現狀制定改進計劃。

    近日百度安全應急響應中心發布了《企業級自動化代碼安全掃描實戰》讀者可以管中窺豹實例了解靜態代碼分析在互聯網公司的落地情況了解該領域的業界的技術趨勢和進展查漏補缺發現企業內部建設不足對標評估自研安全能力立足自有工具現狀制定改進計劃。 

    一、概述

    軟件安全行業在全球不斷出現重大安全事件的敲打下于設計階段、協議、編譯階段、框架實現、加密方案方面已經有了眾多優秀改進各項軟件工具包括p3c、npm audit fix、findbugs可以讓研發人員更快速得實現健壯的代碼商業安全工具和開源社區共建如nodejsscan、findsecbugs、golint、rips協助安全人員相對準確地找到安全缺陷企業專職安全團隊中SDL人員的完善投入和和專業化使得安全組織可以發力于流程建設和應急響應。安全審計人員主要任務逐步為將自動化融入到技術之中。但是業界每個公司的看到的“微軟安全開發生命周期”已經耦合于組織內部的開發模式或者自稱為敏捷sdl實現難以移植值得慶幸的是源代碼審計環節可以快速適配企業在各個階段的安全建設固定作為價值交付的產出。源代碼安全檢測普遍做法一般為人工reviewseay、ctrl+f、ide輔助詞法分析階段使用支持各種語言的多項開源源代碼安全檢查工具增改適配規則導出查看分析報告驗證重視安全的企業采購商業源代碼安全工具在具備二次開發和調用api接口的情況下同企業內部的jira、禪道、漏洞平臺打通結合起來達到運營閉環和數據推動改進效果。

    大型企業一般面臨三個問題

    1、不同部門用的技術棧不同前后端技術也不一致要對不同開發風格適配和維護各項開源工具的編譯命令和規則、報告并不現實所以一般是使用商業安全工具為基礎設施進行一套自動化的代碼掃描接入和推廣在追求覆蓋率的情況下實現對不同部門業務線制定不同的掃描規則和“門檻指標”。

    2、存量代碼太多由于基于svn、gitlab、stash各有各的痛點在沒有存儲和代碼檢索平臺的情況下人工無法在應急響應時快速準確判斷是否受影響、在事后難以增加判斷增量的感知控制手段。大量新增代碼不同分支、對應不同線上線下域名、環境、發布平臺。任何一件事的量級增加都是對工程化的巨大考驗。

    3、人力緊張知道安全專家接入到需求階段效果最好成本最低但是依賴人工終將處于疲勞的應接不暇的階段而人的工作終究會有漏報在事后回顧aar時也沒有更好的改進手段只能做專項。如果黑盒掃描器一樣源代碼的高階實現有且只有依賴于自動化手段。

    為什么要做安全部門自己做源代碼檢測企業內部配置的專職QA或者RD自測時通過測試用例來保證需求清單的功能特性得到實現這種前提下將漏掉一些安全方面的考慮缺失對軟件安全缺陷的檢測。由安全部門制定檢測規則可以具備更好的準確性、及時跟進和可信度也有利于后續的度量。

    什么是漏洞源代碼檢測的安全和質量部門的檢測有何不同:

    image.png

    因源碼掃描作為安全運營的一個階段將安全流程在需求、架構、設計、編碼、測試、驗證階段進行度量和維護。

    image.png

    二、自動化代碼挖掘技術

    基于污點傳播分析的自動化挖掘技術

    回顧下有經驗的安全測試人員在實施人工代碼審計時的流程來觀察思考軟件該怎么做。首先靈活指定和假定輸入源是否可信、能否被污染這類似于參考了威脅建模的信任邊界和數據流概念一般認為來自于網絡請求header、cookies、參數socket網絡通訊數據庫存儲的數據是不可信的當然你可以設計來自于環境變量、配置文件、反序列類為不可信據此可以指定需要關注的程序內部函數繼續分析查看上述的污染源是否經過安全處理即凈化。這里的安全函數如阿里的midway-security、owasp的esapi檢測和識別會是誤報較多的場景有時候掃描工具不支持識別該凈化函數有時候是對漏洞理解不足導致凈化函數使用不正確。安全團隊在實施時也會考慮提供凈化函數提供給業務接入以簡單高效解決問題最后在修復階段需要復查是否是完善的修復方案能否被繞過、凈化函數的覆蓋率。最后是觸發階段審計時執行測試用例希冀被危險函數觸發執行。所以這是一種基于數據傳遞流程進行的一次檢查。

    了解到上面的普遍性技術就清楚整個檢測技術的要點文章介紹了php的檢測思路具體可以看看cobra的代碼實現。其實對于java各自框架和反射機制、nodejs靈活的框架和寫法非商業工具還是會遇到各項困難有時候直接用正則匹配未必不是一個捷徑反正都是基于規則進行檢測的只要保證低誤報率即可。

    三、企業級研發與部署方案

    企業級實際場景和挑戰

    商業掃描基于license的情況一般是不直接安裝于rd的個人機基于ide也需要在本機安裝掃描軟件找八哥、checkmars基于云、coverity、foritify、cobot笨重以至于華為公司需要安排專職人員負責持續集成來搭建環境進行代碼編譯掃描后再上傳到商業安全工具平臺導出結果。而結果直接交給業務線并不能統計和保證效果最后出現安全問題還是被認為沒有將安全能力賦予業務。哪怕提供了詳細的報告報告的可讀性、整改實際情況都是一項挑戰。

    安全人員順其自然想到做一個平臺支持推廣、自動化功能和接入實現系統工程化的集中管控任務序列處理、工單聯動最后出具圖表通知和提供api進行對外輸出。

    軟件上線前必須通過安全掃描隱含的前提是需要明確卡位哪些是新業務對于迭代任務是否需要接入將安全作為一個環節融入在軟件研發的持續集成活動中。

    安全紅線在于指標在確定掃描規則的準確性的情況下可以對不安全的組件、嚴重、高危漏洞進行阻斷發布。

    整體架構

    架構方面大都類似掃描接口獲取到任務上線列表、復查請求、手動創建任務、創建策略依據優先級指定掃描規則下發至CI進行編譯異步檢測是否成功、推送掃描結果ci帶動掃描引擎將商業安全工具和自研的規則跑起來引擎管理層收集結果入庫或本地生成報告。在源代碼管理層配置各項賬戶拉取代碼由于部分語言的代碼掃描時需要編譯需要將代碼保存在機器上。痛點是數據量大存在同企業發布平臺拉取的代碼重復的情況這里建議將代碼做索引以便搜索和查詢。比對汽車之家的源碼平臺建設可以看到百度在任務管理、增量存儲方面做得更為先進。

    SDL中實踐

    由于將安全掃描作為發布的必須環節實際上將業務的編譯階段相當于重復了一次必須保證掃描結果較快基于解釋性語言的話掃描會慢得多。這里的增量策略的必要性在于某些掃描引擎不支持增量掃描所以開發匹配識別增量文件擴展拉取引用的函數和代碼文件補全語義分析或者控制流分析流程。好處是這里可以清晰地獲取到數據的調用流轉過程程序自動對此生成調用關系鏈圖幫助業務在修復時快速了解漏洞的前因后果減少人工答疑時間。

    無變更文件不進行掃描的特殊場景是賬戶密碼文件等不經常變更需要對此進行甄別識別配置文件明文密碼的情況。

    企業內部凌晨反而經常是資源緊張的時候可以單獨跑序列對掃描失敗的任務、漏洞已經修復待檢驗的代碼在周末進行復掃自動關閉工單。

    平臺檢測效果

    從效果上看增量的任務可以保證完全接入對于存量可以人工接入存量的經常是找不到漏洞責任人。10min內發生的事情有漏洞規則方面應當支持src收集的公司典型漏洞和owasp通用漏洞源碼分析的不足是不能發現業務相關的漏洞如越權、信息泄露。

    java漏洞檢測的組件方面可以查詢配置文件對于多module的情況需要識別version的配置最后需要維護同cve的對應關系。

    發表評論

    已有 4 條評論

    取消
    Loading...
    css.php 宁夏卫视在线直播观看