將安全措施納入開發與建置流程

建置流程中的主要元素自動化，可大幅縮短開發團隊從設計到正式上線的時間。亦即更快完成功能開發、正式上線，會是相當好的成果。然而，這些自動化流程雖能免除大量手動處理程序，卻可能增加解決方案的弱點，也容易將不安全的程式碼導入正式上線環境。

本章將探討將安全措施納入開發與建置流程的方式，以克服這些挑戰。

設計

在設計階段，會由商業分析師、IT 與安全架構師，共同建立功能性與非功能性需求的待辦清單。這也是開發團隊為待辦事項與缺失之處排列優先順序的階段，這是遭遇的第一個摩擦。開發團隊面臨部署功能性的壓力，往往會調降預防作業與待辦事項中安全性功能或缺陷的優先權。

除了功能性與非功能性需求的定義外，識別濫用案例亦有助於後續測試期間檢測應用程式的商業邏輯漏洞。OWASP SAMM 專案將誤用與濫用的案例定義為：誤用與濫用案例乃描述意外與惡意的應用程式使用場景，說明攻擊者的做法。

濫用案例定義功能的濫用，亦稱商業邏輯攻擊（business logic attacks）。我們透過定義重要商業規則的功能性需求，來定義濫用案例，驗證應用程式是否正確施行商業規則。

電子商務購物車的濫用案例

試想以下電子商務購物車場景，攻擊者試圖不當利用電子商務網站的商業邏輯獲得折扣。可以找出的濫用案例如下：

限時優惠濫用（Abuse of time-limited offers）

若網站提供限時促銷或折扣，攻擊者可以操控系統時鐘或利用其他技術延長促銷期間，在限時促銷優惠之外的時間繼續獲得較低費用。

操控品項價格（Manipulation of item prices）

試想電子商務網站消費者將商品放進購物籃、計算總價再結帳的過程。系統的商業邏輯是正確計算品項價格、套用折扣，再處理購物車。攻擊者會試圖從另一個角度操控定義，不當利用程式的缺陷，例如試圖截取並操控客戶端與伺服器間的通訊，改變購物車裡的商品價格，或者變更商品數量或單價，以利支付比實際價格更低的款項。

濫用有弱點的折扣程式碼（Abuse of weak discount codes）

許多網站為顧客提供折扣碼。有些網站僅驗證程式碼語法，而不是實際程式碼本身，等於說攻擊者只需要了解底層語法就能獲得折扣。

這是三個可能的濫用案例，但其實還有更多。對商業邏輯的理解越深入，就越能發掘可以濫用的方式。

理想流程是由商業分析師確立功能性需求，再以此為基礎與安全架構師協同開發濫用案例，這些案例會觸發定義因應措施的需求。

開發

在開發階段，開發人員負責發展實際的程式碼，同時培訓實際撰寫安全程式碼。針對使用的程式語言建立安全程式碼撰寫實作指南，是不錯的作法，開發人員可以將許多靜態應用程式安全測試（SAST）的工具整合到 IDE 裡，在開發階段找出潛在弱點，手動撰寫安全程式碼或同儕審核，都是此階段找出潛在安全問題的有效手段，卡片支付產業資料安全標準（PCI DSS）v4這類標準，就要求審核自訂與客製化的程式碼。OWASP Code Review Guide概述開發安全程式碼的審核流程必須考量的要素如下：

風險（Risk）

完整審核來源程式碼是不切實際的做法，團隊應以風險為基礎考量，選擇必須手動審核的元件與方法。

目的與背景環境（Purpose and context）

從風險管理的角度來看，理解應用程式的目的與背景環境也是一大重要考量。例如，支付服務所需的安全等級，顯然高於員工餐廳菜單網站。

程式碼行數（Lines of code）

程式碼行數定義所需工作量，也代表可能出錯的數量，因為程式碼行數越多，出錯的可能性也越高。

程式語言（Programming language）

有別於 C 或 C++ 這類語言，部分程式語言例如 Java、C# 由於其語言特性，較不易受到特定安全問題的影響。

資源、時間與時限（Resources, time, and deadlines）

時間當然是關鍵考量，因為手動審核所需的時間與程式碼的規模直接相關。

除了安全程式撰寫的實作，開發階段建立程式碼變更的可追溯性也很重要。開發團隊無論規模大小，常見做法是採用如 Git 等程式碼儲存庫工具，這不僅能確保程式碼變更的可追溯性，也能讓所有開發人員都能協同合作。

建置與包裝

在建置與包裝階段，開發人員會使用各種 script 與工具，自動化軟體的編譯、測試與包裝。我們運用技術，在 CI／CD 管道裡自動化安全測試。針對原始程式碼、容器組態與映像檔的測試表列如下：

靜態應用程式安全測試（SAST）

分析應用程式原始程式碼找出潛在安全弱點。這類測試有助於在應用程式部署前，檢測出常見程式碼的撰寫錯誤，例如緩衝區溢載或 SQL 注入等弱點。SAST 工具逐行掃描來源程式碼，尋找能指出安全性問題的模式或程式碼片段；找出弱點後，開發人員就能採取相應措施來修復。

軟體組成分析（SCA）

軟體開發生命週期中，採用開放原始碼的元件已是常態，開發團隊必須掌握這些元件在應用程式中的部署狀況，以及整合的元件是否含有安全漏洞。軟體組成分析（SCA）有助於識別軟體中可能暴露安全風險的漏洞或過時元件，還能偵測載用特定軟體引發的授權問題，或合規性違規議題。

軟體物料清單

SCA 工具協助建立並維護軟體物料清單（SBOMs），包括使用到的所有第三方元件的版本與許可權等資訊。美國政府發布促進國家網路安全的執行命令後，SBOM 成為焦點，它要求想與美國政府做生意的公司，全面盤點組成應用程式的所有元件，以提高安全性等級；歐盟也在 EU Cyber Resilience Act裡列入 SBOM 要求。另一例是 2021年，在普遍使用的日誌記錄模組 Log4j 發現的重大漏洞「Log4Shell」，由於Log4j 在企業級產品與開放源碼軟體中的應用過於廣泛，導致許多企業組織難以追蹤其部署位置。想更了解 SBOM，請參閱 CISA SBOM。

機密掃描（Secrets scan）

開發人員經常把密碼或 API 金鑰這類機密直接寫在來源程式碼裡，這會產生遭對手不當利用的弱點。機密掃描旨在掃描程式碼的儲存庫、密碼及存取金鑰這類機敏資訊的其他資料來源，有各種工具與處理方式可以完成，例如可找出符合特定機敏資訊種類模式的正規表示式。一般而言，原始程式碼、容器映像檔、組態與基礎結構即服務裡，都會有機密資訊。

安全組態檢查（Secure configuration check）

程式碼編譯完成，通常就能部署在容器裡。容器映像檔與其組態會接受弱點掃描、驗證映像檔完整性，與確保遵循企業組織的資安政策與強化指南。許多企業組織以CIS Benchmarks作為強化指南的依據。

這個階段建置的人為產物，最終會儲存在人為產物儲存庫，以便後續處理時自動化部署至測試、預演與正式上線環境。

書名 混合雲安全架構｜零信任原則的安全設計方法與實作（Security Architecture for Hybrid Cloud）

Mark Buckwell, Stefaan Van daele, Carsten Horst／著

歐萊禮、碁峯資訊出版

定價：780元

作者簡介

Mark Buckwell 是擁有30年架構與交付安全解決方案經驗的雲端安全架構師、思想領袖、演說家與訓練師。

Stefaan Van daele 是IBM網路安全服務的區域CTO與安全架構師。

Carsten Horst 是安全架構師，也是具有25年經驗的IBM副合夥人。