GSS資安電子報0209期 【強化軟體供應鏈安全，讓駭客無從下手！】

    當今惡意攻擊活動逐漸將目標鎖定在應用系統層面，對於仍採用傳統應用系統資安策略的公司面臨極大的挑戰。為了在變化快速的威脅環境中自我防護，公司需要建立新型的應用系統策略，才能應付瞬息萬變的局勢，但該怎麼做呢？
在最近的一場線上研討會中，Mend產品管理副總裁 Jeff Martin 與 Forrester 的資深分析師 Janet Worthington 討論如何維護新一代應用系統資安的最佳策略。

從 Shift Left 到 Shift Everywhere

    主流關心的趨勢大概就是資安工具在軟體開發生命週期（SDLC）的哪一個階段執行。近幾年來，Forrester 在其應用系統資安調查年報中指出「Shift Left」的概念越來越受推崇，我們看到許多公司表示在開發階段開始執行靜態分析。業界大多數人逐漸有了共識，認為不該等到上線階段才開始資安測試，而是應該在 SDLC 早期階段，在問題還未複雜化前，更容易執行修復。

    Worthington 提到業界開始會在開發、測試、上線階段甚至於設計階段就要設想更多。包括資安的 Shift Left 以及 Shift Right，將此統稱為「Shift Everywhere」，其中的原則是：若想維護應用系統以及應用層面的資安，便不能僅僅在單一時間點評估安全性。開發者一定要考慮到延續整個軟體開發生命週期的安全性，並且將資安測試投入於產品發表前的開發層面。Worthington 表示：「業界越來越多的團隊已經將資安測試與自動化整合進 pipeline，所以一切更簡單了。不必特別記得要開始這些工作，因為它已經整合在你的 pipeline 裡了。我們發現越來越多人想要在開發和測試階段採用這樣的技術，而軟體組成分析（SCA）便是其中的先峰，在所有的測試工具中，它是最多人使用的。」

    不過業界也會採用其他測試種類，Forrester調查中，42％ 的受訪者規畫在開發階段採用動態分析，44％ 的受訪者則是規劃在測試階段時採用。在過去，動態分析通常會在 SDLC 即將結束時進行，但最新調查顯示此工作正在 Shift Left，讓資安測試平均分布在整個 SDLC 中。

    Martin 表示：「我喜歡 Shift Everywhere 這個做法，因為在現實層面，每個人都知道不能只在一個環節測試資安，或至少大家開始理解測試應該要在各個階段進行，而只靠一種應用系統資安防護是遠遠不夠的。SAST（靜態應用系統安全測試）測試的是程式中特定種類的缺陷；SCA(軟體組成分析)能測試你的函式庫和已知漏洞，特別是來自開源軟體這種可重複使用的元件；DAST(動態分析)能幫助你過濾並找出真正的風險因子。事實上，這些措施沒有任何一個能單獨撐起新一代應用系統資安的解決方案。你一定要考量這些不同的測試機制，同時需要讓各工具間有相互的關聯，才能全方位的找出潛在的風險與解決。在各個階段、利用各式測試工具進行資安測試。不止專家這麼認為，由這份調查結果也顯示業界已經普遍領悟這個道理了。

政府的促成與SBOM的興起

    說到資安，便不能不說到 2021 年 5 月美國總統針對改善國家網路安全頒布的行政命令。Worthington 形容該行政命令「可能是過去好幾年以來，資安產業中最令人振奮的消息。」她尤其關注此命令對於改善軟體供應鏈的要求，特別是命令美國國家電信暨資訊管理局（NTIA）將軟體物料清單（SBOM）列入最低規範的要求。Worthington 認為，SBOM 是真正知道軟體商品的內容物以及是否帶有任何風險的關鍵。而對於了解購買或下載的任何開源產品中哪些元件，SBOM也同樣重要。如此一來，當出現如同 Log4j 的漏洞時，便能有所警覺，並迅速採取必要措施來避免或減輕損害。這種漏洞事件更證明公司及政府機關在購買或取用軟體時務必僅任遵照規範。Worthington 表示：「我們需要軟體供應鏈呈現更多的透明度，也確實看到政府在落實這樣的觀念。」

    這樣的影響範圍是十分廣泛的，因為即使公司跟政府沒有合作交易，也需要確保資安軟體供應鏈並提供 SBOM。Martin 提到：「我們開始會在購買軟體時要求提供軟體物料清單。當你向大型、規模龐大的企業販售軟體時，已經有明文規定須提供軟體物料清單了。我想這就是我們邁進的第一步，建立軟體商之間更加透明且正規的信任流程。」

     事實上，這是有跡可循的，這種方式已經在醫療器材產業中實施70年。在器材植入某個人體內之前，一定必須知道每個零件以及每根螺絲是從哪裡來的。

    Martin表示：「基本上信任關係是需要記錄起來的，取得像軟體物料清單的產出物是必要的。而我認為再過三到五年這個階段大致完成後，將會看到更進一步的發展，業界可能會開始普遍要求提供已知漏洞清單的資訊。我們注意到現在很多人會談論 VEX平台（弱點資訊交換平台）。大家想要的不只是一份列出所有內容物的清單而已，還想知道從中知道了些什麼，這些元件有什麼問題，以及是怎麼解決這些問題的呢？所以，我想企業的規範很快就會比政府的政策更上一層樓了。」

如何建立好的SBOMs？

     以 Forrester 客戶來說，他們希望知道如何向賣方和供應商索取 SBOM，以及當顧客要求提供 SBOM 的時候該怎麼做。NTIA 的 SBOM 規範側重在以下主要領域，也就是一份好的 SBOM 基本的要素：

• 資料欄位：SBOM 應包含哪些資訊能保證其全面性與可靠性。
• 自動化：SBOM 的生產並非一次性的，應該要隨著應用系統的建構而不斷更新，如此才能提供最佳效益。
• 格式：最常使用的兩個格式為 SPDX 與 CycloneDX。
• 實踐與程序：更新 SBOM 的頻率、如何發布，以及有哪些人可以取得？

    然而，Worthington 極力主張組織須要求獲得比這些最低規範更多的資訊，對所有元件、相依項目和其相依關係有清晰的能見度與了解，如此一來才能真的知道購買的是什麼東西。進行以下步驟，即可幫助公司為此做好準備：

• 盤點軟體供應鏈
• 記錄任何供應鏈與第三方風險問題，並提出緩解方案
• 與供應商溝通，索取 SBOM 與漏洞報告
• 販售的軟體及套裝中的開源軟體自動化建立 SBOM
• 跨部門合作以落實軟體供應鏈資安，包含法律、授權許可、資安，開發部門人員與其他利益關係人

    強烈建議供應商能夠積極主動並公開誠信，因為你不會希望客戶取得 SBOM 後卻回報更多漏洞，並且質問該如何解決。這會讓客戶心中疑慮油然而生，進而動搖信任。

    另外，SBOM 本質上就是機器可讀的格式且是由機器生成的，故其建立與使用應是可自動化的。人工建立的版本是絕對不夠詳盡的，建立的速度也不夠快速。SBOM 需要迅速涵蓋多層的相依項目，因此只有自動化才能隨時準備好在有需要的時候即時提供訊息。而且要知道，因為「Shift Everywhere」的關係，較晚進入建構週期的項目，像是部署、基礎架構以及Containers，都應建立物料清單。

軟體組成分析（SCA 的角色）