DevSecOps五個需要關注的編碼問題

導讀	DevSecOps實現的一大關鍵在於“安全左移”理念。程式的安全不再只是在軟體開發完成後進行測試進行，而需要全週期的分析，及時地發現和修復；而達成這個目標的工具之一就是靜態分析（SAST）。

在過去的軟體開發流程中，安全總是在開發的最終階段進行——雖然這個時候發現的漏洞其實能在更早的階段就被修復。如果要在當下複雜的開發環境中進一步加速的同時還能保障軟體的安全性，開發者就需要將安全左移，更早地將安全融入開發週期中。

但是安全在開發週期的左移並不容易，開發人員會面對不少困難。以下是五個最常見問題——這些問題都能透過靜態分析解決。

記憶體讀取錯誤會因為洩露敏感資訊對機密性和完整性帶來潛在的威脅，而記憶體寫入錯誤則因為會改變工作流而對機密性、完整性和可用性都帶來影響。比較常見的記憶體問題有緩衝區溢位、緩衝區不足和釋放重利用。這些問題難以檢測，甚至存在於一些經過反覆測試，被認為是安全的程式碼裡，因此即使是最有經驗的程式設計師也難免會產生這些問題。儘管說一些程式碼標準被啟用，試圖減少記憶體錯誤，但是顯然不那麼有效。因此，在開發週期早期，需要深度靜態分析、資料流分析、符號執行等方式檢測記憶體錯誤。

這類錯誤主要由C/C++的錯誤使用引起，比如未初始化變數、重複釋放指標、以及間接在徵兆資料和非徵兆資料之間進行變化等。程式設計錯誤中有一部分會被利用進行攻擊，而且即使這些錯誤會導致程式崩潰，可能也不會在功能測試和迴歸測試中顯現出來。然而，它們確實會在部署的系統中引起嚴重問題。靜態額分析可以識別在程式設計語義中存在的程式碼錯誤和歧義。

有一些API函式被認為是有隱患，不安全的。比如C/C++中的gets()函式，就很容易產生目標地址的快取溢位問題。其他函式呼叫也可能因為一些行為產生危害。這類有風險的函式呼叫很容易就在靜態分析中透過風險函式列表的方式被識別。

密碼學在保障資料機密性的環境中尤為重要。但是，幾乎沒有開發人員在密碼學層面是專家；更糟的是，濫用C語言本身庫裡的密碼函式反而會導致安全問題，比如使用像DES和MD5那樣的弱演算法加密，或者用硬編碼的金鑰以及將鹽資料進行雜湊。密碼學的濫用會影響機密性和完整性，不過他們也同樣能被靜態分析輕鬆識別。

汙染資料是指資料在進入系統時未被驗證並去除有害內容，從而無法保證資料值是在合法範圍。汙染資料是對開發者最大的挑戰之一，同樣也會影響機密性和完整性。人工檢查很難檢測到資料注入問題。

如果要解決汙染資料的問題，就需要對以任何形式（比如使用者、裝置、sockets等等）進入系統的資料都從來源到目標進行追蹤。在資料被API呼叫、接入資料結構、或者進入任何程式設計邏輯前，都需要被驗證。否則，就可能產生資料注入的攻擊威脅。靜態分析可以在工作流中進行計算，提供簡明易懂的告警保住程式設計師規避這些危險情況。

靜態分析，或者說靜態分析安全測試（SAST），透過檢查源程式的程式碼來檢測可能的安全問題——比如啥上述的五個程式碼問題。由於SAST可以被用於開發者的CI/CD工作流中，它不會減緩敏捷開發程式。實際上，因為它能在開發者編寫程式碼的時候發現漏洞，從而減少發現問題的成本，並在應用上線前——甚至在進行測試前就進行修復，最終加速軟體開發速度。因此，SAST對提升程式碼安全性有著關鍵的作用，需要成為在DevSecOps的安全左移過程中的一部分。

在安全左移的過程中，程式碼的即時分析、測試並發現漏洞是一大重點。本文提及了SAST在DevSecOps中能解決的一些程式碼問題，但是SAST並不是DevSecOps過程中的唯一工具，同樣需要結合IAST、軟體供應鏈管理等工具，才能完善DevSecOps工具鏈，逐漸增加自己的軟體開發週期的安全度。