本文分享自華為雲社群《構建DevSecOps中的程式碼三層防護體系》,作者:Uncle_Tom。
在DevSecOps的應用過程中,靜態分析工具在開發階段承擔著非常重要的程式碼質量和安全的看護任務。本文根據開發過程的不同位置的開發環境、程式碼特徵以及檢測工具能力的差異,提出了需要因地制宜地部署檢查工具,形成遞進的三層程式碼安全防禦體系,從而提高應用軟體整體安全性,同時又能有效的貫徹安全左移的策略,降低安全問題的維護成本。
1. DevSecOps
近年來,大型企業DevSecOps引入佔比逐年遞增,從2020年的41.3%增至2022年超63.5%, 其複合增長率超過20%。
DevSecOps一詞最早由Gartner在2012年提出,並在最近幾年逐步成為軟體開發種的熱點。DevSecOps在開發人員、測試人員、安全團隊和運維團隊之間架起了橋樑;它改善了團隊之間的溝通和協作,其目標是更快、更高效地交付。DevSecOps,在DevOps的基礎上增加了安全的活動,在保障快速開發、快速的部署的基礎上,提高了安全性,內嵌安全到應用程式中,能夠更迅速地應對安全威脅。
下圖是美國國防部(Department of Defense(DOD)) 定義的DevSecOps軟體生命週期的9個階段:計劃、開發、構建、測試、釋出、交付、部署、操作和監控。安全嵌入到每個階段。DevSecOps生命週期具有很強的適應性,並且有許多反饋迴圈來驅動持續改進。DevSecOps 在管理理念、管理方法、組織結構、開發流程、軟體開發、開發平臺、工具整合、以及企業文化等方方面面對傳統的軟體開發提出了新的挑戰。
在DevSecOps的應用過程中,靜態分析工具在開發階段承擔著非常重要的程式碼質量和安全的看護任務。本文重點講述軟體靜態分析工具在DevSecOps的開發域中的重要作用。
2. DOD DevSecOps
美國防部自2021年起釋出一系列關於DevSecOps相關檔案:《國防部企業DevSecOps戰略指南》、《國防部企業DevSecOps基礎》、《DevSecOps參考設計》《DevSecOps行動手冊》等相關支撐檔案。
今年五月又補充了《DevSecOps 基礎指南:活動和工具》。在這個文件中更加清楚的定義了在DevSecOps的生命週期中,需要完成的安全活動和對應的工具。涉及的安全活動如下表:
安全活動 | 階段 | 依賴的工具 |
---|---|---|
基於任務的網路風險評估 | 全部 | 基於任務的網路風險評估工具 |
威脅建模 | 計劃 | 威脅建模工具 |
程式碼提交掃描 | 開發 | 程式碼倉安全外掛 |
安全程式碼開發 | 開發 | IDE |
提交前的靜態程式碼掃描 | 開發 | IDE 安全外掛 |
依賴元件漏洞檢查 | 構建 | 依賴關係檢查/物料清單檢查工具 |
靜態應用程式安全測試和掃描(SAST) | 構建 | 靜態應用程式安全測試和掃描工具(SAST) |
資料庫安全測試 | 測試 | 安全合規工具 |
動態應用程式安全測試和掃描(DAST) | 測試 | 動態應用程式安全測試和掃描工具(DAST)或 互動式應用程式安全測試工具(IAST) |
互動式應用程式安全測試(IAST) | 測試 | 動態應用程式安全測試和掃描工具(DAST)或 互動式應用程式安全測試工具(IAST) |
手動安全測試(如滲透測試) | 測試 | 各種工具和指令碼(可能包括網路安全測試工具) |
服務安全測試 | 測試 | 安全合規工具 |
部署後安全掃描 | 部署 | 安全合規工具 |
合規監控(資源和服務) | 監控 | 合規工具、操作看板 |
合規性監控 | 監控 | 合規工具、操作看板 |
資料庫監控和安全審計 | 監控 | 安全合規工具 |
執行時應用程式安全保護(RASP) | 監控 | 安全合規工具 |
系統安全監控 | 監控 | 資訊保安持續監控 (ISCM) |
SBOM 軟體組成分析 | 構建後期 | SBOM和軟體工廠風險持續監控工具 |
軟體工廠風險持續監控 | 構建後期 | SBOM和軟體工廠風險持續監控工具 |
介面安全測試 | 構建 | API 安全測試工具 |
合作和對抗測試 | 運維 | 合作和對抗測試工具 |
持續網路運營測試 | 運維 | 持續性網路運營測試工具 |
工程混淆 | 運維 | 工程混淆工具 |
從這個活動表我們可以看到在開發過程中,有三個關鍵的安全檢測點, 即表格中我們標紅的部分),以及檔案中關於這三個檢測點的資訊合併成下表:
活動 | 基線 | 描述 | 輸入 | 輸出 | 依賴的工具 |
---|---|---|---|---|---|
程式碼在提交前的靜態分析 | 要求 | 在開發人員編寫程式碼時對程式碼進行掃描和分析。通知開發人員潛在的程式碼弱點並提出補救建議。 | 原始碼、已知弱點 | 發現程式碼中的弱點問題 | IDE外掛 |
程式碼提交檢查 | 要求 | 在將更改推送到程式碼倉之前,請檢查更改中的敏感資訊。如果發現可疑內容,它會通知開發人員並阻止提交。 | 本地提交的程式碼 | 檢出的安全問題和警告 | 程式碼倉安全外掛 |
靜態應用安全測試 | 要求 | 對軟體系統執行靜態分析檢查 | 原始碼、已知的安全問題和弱點 | 靜態檢查報告和修復建議 | 靜態分析工具 |
從這個表格我們可以看到,在程式碼的開發階段在以下檢測點需要完成相應的靜態分析檢測:
- 在IDE,透過IDE安全外掛,對需要提交的程式碼完成安全檢測;
- 在程式碼倉,透過安全外掛,進行的程式碼提交掃描,也是我們常說的“門禁”;
- 在構建,透過靜態分析工具,完成靜態應用程式安全測試和掃描(SAST)
《DevSecOps 基礎指南:活動和工具》中,只提出了對流程檢測點的需要有的活動要求和工具的粗略的要求,並沒有給出具體的流程融合和該怎麼在不同的檢測點如何選擇工具。
3. OWASP DevSecOps
開放全球應用程式安全專案(Open Worldwide Application Security Project (OWASP)) 是一個非營利性基金會,致力於提高軟體的安全性。基金會致力於透過其社群主導的開源軟體專案,全球數百個分會,數萬名成員以及舉辦本地和全球會議來提高軟體的安全性。
《OWASP DevSecOps 指導(OWASP DevSecOps Guideline》)指導我們如何實現安全管道和使用最佳實踐,並介紹了可以在這件事上使用的工具。
指導在DevSecOps的實踐中,還特別用一個章節介紹了預提交(pre-commit)的流程。如下圖:
這張圖清楚的給出了預提交的檢查流程,並給出了在預提交中需要完成的兩種檢查:
- 確保程式碼中沒有密碼、金鑰問題;
- 程式碼遵循Linter 規則。
這裡的Linter 我找不到一個合適的中文來翻譯這個英文。Linter 本意指的是衣服上在洗衣機洗完後,由於滾動摩擦會使衣物的纖維聚集在一起形成絨毛或纖維等的小球。以前想把這些多出來的"小球"去掉, 後來人們發明了叫Linter的神器,一滾就能清除掉這種"小球"。
1978 年,工作于貝爾實驗的Stephen C. Johnson 在 Debug 自己的 C 語言專案時,突然想到為什麼不做一個工具來提示自己寫的程式碼哪裡有問題呢? 這個工具也被稱為 Linter。Linter是一種靜態分析工具,主要用於發現程式碼中語法錯誤、潛在 Bug、程式碼風格等。我們常見的以lint命名的各種工具就是這一型別的靜態檢查工具。幾乎每種語言都有自己語言的Linter工具,例如我們熟悉的:Java:checkstyle,Javascript:ESLint,Python:PyLint,C/C++:cpplint、Go:golint等等。
-
《OWASP DevSecOps 指導》中,給出了Linter的作用:
- 檢測程式碼中的錯誤以及可能導致安全漏洞的錯誤;
- 檢測格式或樣式問題,並使程式碼更具可讀性,從而獲得更安全的程式碼;
- 檢測建議的最佳實踐;
- 可以提高程式碼的整體質量;
- 由於每個人都遵循相同的 linting 規則,因此程式碼的維護變得更加容易。
-
《OWASP DevSecOps 指導》中,將靜態檢查工具的按檢查問題的不同定義成Linter 和 高階靜態檢查工具:
-
Linter工具是靜態分析的最基本形式。使用 lint 工具有助於識別常見錯誤,例如:
- 陣列索引越界;
- 空指標解引用;
- (潛在)危險的資料型別組合;
- 無法訪問的程式碼(死程式碼);
- 不可移植的結構。
-
高階靜態分析工具。高階靜態分析工具通常提供:
- 基於模式的檢查;
- 質量和複雜性指標;
- 面向開發人員的最佳實踐建議;
- 支援多種以安全和安保為重點的編碼標準;
- 用於開發安全關鍵型應用, 例如:開箱即用的認證。
-
《OWASP DevSecOps 指導》給出不同工具檢查缺陷型別的不同,主要還是說明在不同的檢測點,需要配置不同型別的檢查工具。
4. 安全左移
Capers Jones在《應用軟體測量:生產力和質量的全面分析》中闡述了從軟體工程實踐角度出發,說明了大部分的問題在編碼階段引入,同時隨著缺陷在開發過程中發現的越晚,修復成本越高。
所以我們希望透過將開發完後的測試工作融入到開發過程中,這樣可以有效的降低開發過程中引入缺陷的修復成本。
-
測試向開發階段左移
-
測試左移,缺陷在開發階段減少
在DevSecOps概念提出後,人們很自然的就提出了"安全左移"的概念。“安全左移”(引自《OWASP DevSecOps 指導》中的定義) 是一種將安全性嵌入到開發過程中的方法或解決方案,並從應用程式或系統設計的初始步驟開始考慮安全性。換句話說,安全性對從事軟體開發和操作過程的每個人負責。當然,安全是一種職業,我們需要高技能的人來扮演與安全相關的角色;但在這種方法中,任何設計師、軟體架構、開發人員、DevOps 工程師和…與安全人員一起對安全負有責任。
從這個描述中我們可以看到安全左移包括幾個具體的活動:
- 安全從設計開始,貫穿整個流程;
- 全員參與安全活動;
根據前面我們對美國國防部《DevSecOps 基礎指南:活動和工具》,以及OWADSP的《OWASP DevSecOps 指導》的瞭解,在開發過程的編碼階段有三個檢查點:IDE、門禁、持續構建(CI)。按照"安全左移"的理念,我們是不是也可以"一路向左", 將靜態檢查工具放到IDE或門禁中,實現靜態檢查工具的左移,從而去掉持續構建(CI)中的檢查環節?是不是可以一路向左?
4.1. 成語故事“因地制宜”
好久沒在部落格裡講故事了。中國歷史悠久、先賢們將各種為人、處事的道理、哲學融匯在一個個故事裡,通俗易懂,並煉成了讓人津津樂道的成語故事,源遠流長,讓普通人都能牢記這些哲理精髓,一代代傳承。最近刀郎紅火起來的歌曲,除了歌曲本身,人們更喜歡挖掘的是歌曲中包含的各種悽美故事。
春秋末年,楚王聽信讒言,殺了伍子胥一家,伍子胥逃到了吳國。伍子胥為了藉助吳國給自己報仇,給吳王獻計:要想使國家富強,人民安定,首先要高築城牆,這樣才能加強防禦力量,使其他國家不敢進犯。還要加強軍事力量,充實武器及物資的儲備,這樣就能夠對別的國家形成威懾之勢。同時還要發展農業,只有農業發展了,國家才能富強,百姓才能安居樂業,將士們才有充足的給養,而且要充實糧倉,以備戰時之需。這樣國家才能安定,才有可能發展。吳王非常贊同伍子胥的戰略。於是巧妙利用吳國的地形,建立起一座依山傍水的城郭。城中有多個城門,且其中三個築有城樓。大城中還有東西兩座小城,西城為吳王的王宮所在地,東城則是駐紮軍隊、存放軍備的地方。就這樣在城中設定守備、積聚糧食、充實兵庫,為稱霸諸侯做準備。經過一段時間的準備,吳國逐漸強盛起來。最後吳軍大舉進攻楚國,五戰五勝,最後攻陷了楚國的國都:郢都。伍子胥終於報了殺父兄之仇。這就是“因地制宜”成語的故事。
從這個成語我們也悟出一個道理,對於開發階段中,對靜態分析的工具使用並不能"一路向左", 需要考慮檢測點的差異, 選取合適的檢測工具,才能建立有效的防禦體系。
4.2. 建立三層程式碼的防護體系
我們透過下表可以清楚的看到三個檢測點的差異,以及根據差異選用不同的靜態檢查工具,從而達到“因地制宜”的效果。
比較項 | IDE | 門禁 | CI |
---|---|---|---|
掃描範圍 | 模組級的程式碼 | 少量修改的程式碼檔案 | 全量的工程程式碼 |
程式碼量差異 | 一般小於<10萬LOC | 修改量一般<500LOC,修改檔案<10個 | 根據工程大小確定,可以達到億級的程式碼量 |
編譯環境 | 部分語言具備本地編譯環境,C語言應編譯器配置複雜 | 不具備編譯環境 | 具備編譯環境 |
工具配置 | 簡單,開箱即用,可以有少量的配置,與IDE融合 | 有一定的配置,需要與pre-commit 融合 | 可以有複雜的配置用於規則的選擇和規則引數的設定 |
工具使用 | 部分開發人員會使用 | 強制。 注:IDE檢查並不能保證開發人員一定執行了檢查任務,這裡透過強制手段,確保程式碼在入庫前完成基本的安全檢查 |
強制 |
分析精度 | 要求工具誤報低,但允許有少量的誤報 | 要求工具工具誤報更低,減少因工具誤報照成不必要的反覆 | 容忍一定的誤報率,建議<30% |
分析效率 | 秒級掃描,不影響本地開發,最好事實完成檢查 | 分鐘級的掃描,建議<5分鐘 | 小時級的掃描,在第二天上班前獲得掃描結果即可 |
靜態檢查工具要求 | 編譯/非編譯型,單檔案分析,基於語法樹分析; 在不影響效率或能到依賴資訊的情況下,適度的進行跨檔案的分析,提高檢查範圍和能力 |
非編譯型,單檔案分析,基於語法樹分析 在整體工程較小的情況下,透過CI完成全量檢查 |
編譯/非編譯, 跨檔案分析,各種檢查能力 |
DevSecOps 在實施過程中除了強調工具的配合實現各個檢測點的自動化,更主要的是需要提供一套完整的工具整合平臺,實現整體流程的自動化執行和監管。這也是為什麼大部分的企業在實施DevSecOps的時候,都選擇了透過雲平臺支撐DevSecOps的實施方式。
5. 華為雲的三層檢查體系
優秀的程式碼質量保障實踐,往往將程式碼檢查融入到開發作業流中,在使用者程式碼編寫、程式碼提交時進行自動化的審計檢查,並對團隊每日產出的程式碼進行持續程式設計規範和質量檢查。
這一活動實踐要求已是安全開發過程SDL、DevSecOps等眾多優秀開發模式推薦進行的實踐要求。
華為雲程式碼檢查服務(CodeArts Check)提供豐富的API介面、涵括任務新建、任務設定、任務掃描、任務報告解析等檢查業務全流程,支援使用者使用介面方式無縫整合到自建CI/CD或者CodeArts,作業資料靈活對接到客戶看板,程式碼質量可視、可管理。
同時透過靈活的任務管理,支援排除目錄設定避免無效掃描,並支援混合語言檢查、簡化部署、一次獲取整個版本程式碼質量。
詳見:“程式碼編寫、程式碼合併、版本釋出”三層缺陷防護,兼顧效率與質量
6. 參考
- DevSecOps Fundamentals Guidebook: Activities & Tools
- DoD Enterprise DevSecOps Strategy Guide
- DoD Enterprise DevSecOps Fundamentals
- DevSecOps Fundamentals Playbook
- DoD Enterprise DevSecOps-Pathway to Reference Design
- OWASP devsecops guidelien
- Capers Jones, Applied Software Measurement: Global Analysis of Productivity and Quality.
-
What Is Shift-Left Testing? - Parasoft