控制措施

如果是自行開發程式,應該透過靜態或動態方法,去發現程式的安全弱點。靜態或動態分析方法的差異,主要在於:

  • 靜態分析是針對程式原始碼或可執行檔本身,在未執行程式或應用系統的情況下,去發現可能的弱點。
  • 動態分析是將程式於可以被監控的環境中執行起來,並產生嘗試去利用程是弱點的輸入,以發現程式是否真有該弱點。

雖然目前已有許多靜態分析工具,然而,工具的發展目前仍有許多限制,有時仍需要人工輔助進行程式碼檢視,甚至比較進階的程式邏輯分析,目前仍以人工檢視為主。因此,通常會在將程式送入分析工具分析之前,先由同儕先進行初步審查,而之後再對工具分析的結果再作檢視。

事實上,不見得一定要非常正式的程式碼審查,只要程式開發者知道程式有另外的人會看,在開發上就會比較小心,當然,也會有覺得會有人在後面把關而疏忽的例子。因此,就程式碼審查來說,按照正式程度,可以分為以下幾種:

  • 隨意審查 (Ad hoc Review):這屬於在沒有計畫的情況下進行審查,例如開發程式開發到一半,請隔壁的同事來看看這樣開發有沒有問題。
  • 同儕書面審查 (Peer Deskcheck):這種方法較前者具有完整性,因為不是單純針對部分的程式碼進行審查,而是全面的去進行檢查。
  • 共同開發 (Pair Programming):簡單來說,這種方法可以是兩個程式開發者使用同一台電腦或工作站進行系統開發。這樣一個人在進行開發的時候,另一個人就可以看到是否有問題。
  • 導覽 (Walkthrough):由程式開發人員向審查人員介紹他程式的流程以及如何進行產出,以便發現問題。
  • 調查 (Inspection):由一個調查團隊,經過規劃,按照一既定的程序去進行程式的檢查。而更強調於對所發現問題的追蹤,與透過因素分析去了解開發流程的缺點以進行改善,。

對於智慧合約程式,因為一旦佈署了之後就很難修改,因此可以更進一步進行正規驗證,以便證明智慧合約不會進入異常的執行狀態。

動態分析通常以工具為主,有時也會搭配靜態的分析技術,去針對程式碼的內容產生測試案例。不過,對於弱點的利用來說,有時會需要輔以人工的幫助,以便能夠針對一般動態工具不足的地方產生測試要求。

不過一般而言,程式碼審查還是以靜態分析為主,動態分析比較常用在系統安全測試的階段。

適用範圍:

  • 應用服務的開發與維護單位

相關標準之控制措施:

標準 相關控制措施
PCI-DSS 3.2.1 6.5、6.6
CIS 控制 v7.1 18.7
ISO/IEC 27002:2013 14.2.1

Updated: