【資安工具專欄】選擇靜態分析工具(SAST) 的 6 大評估項目

該如何挑選擇靜態分析工具(SAST, static application security testing) 是安全專家、 稽核人員、開發人員都會面臨的問題。選擇一 個好的工具需要考量不同的層面，以下為挑選 工具時的需求：

1. 支援語言 確認SAST 工具支援所使用的語言。 
2. 存取原始碼及binary code 部份SAST 工具只會檢測原始碼，但有 些會連同binary 一同處處理。相較於原始碼檢測，binary 檢測需連同建置環境一併提供，以便進行檢測。
3. 部署 確認SAST 工具作業方式：於單位內部或是採用雲端架構。
4. 對於組織內部程式碼安全訂定責任歸屬 定義在組織中如何管控程式碼的安全性。如有個團隊〈審核團隊、資訊安全團隊〉專職負責組織內的安全事務。另一方面也有組織認為每個開發團隊都需要專人負責安全。這些管理政策將影響SAST工具的部屬架構、授權與工具的用法。

階段1：安裝

簡易安裝，應包含以下步驟。

1. 資源：工具安裝為自動安裝還是手動安裝。 若手動安裝，需考量所需的技能以及安裝 工時。
2. 彈性：若為用戶端軟體，需安裝在每個終 端的設備中，並要求每位開發團隊暫時無法作業，以便進行安裝。另一種集中管理 的安裝只需進行一次。
3. 授權：有些軟體授權是各終端設備皆需計 算license 授權。有些則是集中管理，如此 可減少購買大量授權的需求。

階段2：設定

需考量以下2 個因素。

1. 困難度及複雜度：
   • 單純：檢測工作需越簡單越好，不應加重使用者的工作量。
   • 語言的擴展性：是否可不需修改設定即可支援新的語言。
2. 檢測時間：無論任何的工具，皆須花費時間檢測。建議考量工具的特性或不同的檢測方法，讓花費的時間有機會加速，如對於開發團隊來說，大型專案中會需要只先 針對專案中部份程式檢測。

階段3：檢測能力

檢測功能包含。

1. 語言支援範圍：工具應不只包含現有的語言，應考量未來新語言的擴充。像是行動 裝置或是發展中的語言(Android, Objective C, Ruby on Rails)
2. Framework的支援範圍：支援framework 讓SAST 工具更能識別原始碼的弱點以及減少因為不認得framework 造成的誤判。
3. 多個檢測：同時運行數個掃描或是支援多工處理。
4. 弱點涵蓋率：SAST 工具應包含以下類型的弱點：
   • 技術安全弱點：偵測已定義常見弱點如 OWASP TOP 10, SANS, CWE。由於每種工具的分類方式不同，因此可以符合上述常見弱點分類來做為弱點涵蓋率比較。
   • 商業邏輯缺陷：包含應用系統中的驗證方式或是後門程式。 最佳撰寫實務：例如錯誤處理與資源競爭。
   • 最佳撰寫實務：例如錯誤處理與資源競爭。
5. 結果的準確性：為確保結果的精準性， 工具應將檢測結果與已知驗證案例比對。 通常會使用OWASP WebGoat 專案做為驗 證案例。然而，真正困難的是針對一個未 知的應用系統來進行檢測，並能主動調整 測試環境以防止發生以下情況：
   • True Positives (TPs) 的數量：事實為真，猜測也為真，則為正確猜對
   • False Positives (FPs) 的數量：事實為假，猜 測為真，則為誤報。現今沒有一個工具能 輸出完全無 FP 的檢測，但仍會以最少數 量的FP 為目標。
6. 客製化能力：能適應不同程式frameworks 與商業邏輯產生檢測結果。每個組織內採 用的framework、資料庫與驗證涵式都不 盡相同，工具必須能客製調整檢測規則， 以減少誤報(FPs)。

階段4：結果管理

檢測結果需要清楚且能快速解決問題。

1. 結果分析與管理工具：結果分析應即時 提供使用者相關安全情報與工具來修復問題。 
2. 報表：應提供多層次的報告。

階段5：與SDLC 的整合

在軟體開發生命周期(SDLC) 中進行程式碼邏輯與技術分析。

1. SDLC 模型—應包含：
2. SDLC 整合—SAST 工具應要能無痛併入作 業流程中。不僅節省開發人員時間，使安全變成開發流程的一部份。建議整合的部份包含：

階段6：供應商的支援

工具購買後並不是結束。而是一個持續的過程。如同任何的工具，購買後可能會 有使用上的問題、最佳的做法或客製化 的部份。皆需考量到供應商提供的服務。

• 匯整檢測結果：將同一專案的所有檢測 結果匯總在一起的能力。
• 弱點流程：提供弱點的程式碼流程，幫助開發人員了解弱點的流程及其意義。
• 最佳修復位置：提供文字或圖像的最佳弱 點描述。如精準的說明有相依性的問題，修復某特定位置即能同時處理多個弱點。
• 標記與過濾能力：可以依據政策對結果分群，並排列出優先順序。此外也提供篩選 的功能輔助結果閱讀。
• 專案結果追蹤：工具需能持續追蹤專案中 每次檢測的弱點狀態。
• 檢測比較：工具應可比較不同的檢測結果，以便監控弱點狀態。
• 儀表板：提供執行摘要等概觀資訊。
• 報表內容：提供檢測配置資訊與結果。
• 早期檢測：盡早在開發過程中進行安全漏洞程式修補。工具應能提供無論程式是否 已編譯，皆可進行檢測的能力。
• 支援敏捷式開發與持續發展環境：敏捷與持續發展( 又名為DevOps) 要求短時間內 需完成掃描並無法忍受任何的延遲 ( 檢測花費的時間及修復時間)。因此工具需整合至開發環境中以便開發人員可執行檢測。
• 再次檢測：可只針對異動部份的程式碼進行檢測，無須再次檢測已分析過的檔案。
• 開發環境：SAST 工具要能無縫融入開發環 境中如Visual Studio、Eclipse 或IntelliJ。
• 建置管理工具：如Bamboo, Jenkins, Maven 及Ant。
• 版本控管工具： 如GIT, SVN, TFS, Mercurial, ClearCase。部份的SAST 工具不 需透過建置管理工具，即可直接整合版本 控管工具。
• Bug 追蹤系統：工具應要能將檢測結果匯入 Bug 追蹤系統，可依據弱點的嚴重性及其他 工作項目安排修復進度。

1. 檢測規則及政策可否依客戶企業調整設定。
2. 技術人員的支援及教育訓練。
3. 在導入及使用 SAST 工具的整個期間，應能回覆客戶的詢問。
4. 組織中軟體開發生命周期與 SAST 工具的整合。