拿回你的主控權！ 守護軟體供應鏈安全 從建立 SBOM 開始
任何資安專家恐怕都永遠無法忘懷 2021 年 12 月 9 日的悲劇。就在這天，被應用廣泛到各應用程式的Log4j Java 日誌資料庫中揭露了一個重大漏洞：CVE-2021-44228，也被稱為Log4Shell，它是一個遠端執行漏洞，讓攻擊者能夠完全控制受影響的系統。在漏洞揭露當下，便有一起漏洞濫用事件也已經被察覺，但這僅是風波的開端而已，更嚴重的問題隨即接踵而至。
該漏洞一出現，就立刻引發全世界各公司機構的倉皇提問：
- 我們有用到 Log4j 嗎？
- 我們用的是哪個版本？
- 我們都把它用在哪？……
回答這些問題看似簡單，實則不然，而且這些世界各地的公司機構，非常有可能不只在單一應用程式執行此開源軟體。根據 SC Media，在超過 3 百萬起漏洞案例中都有偵測到 Log4j。而在此時此刻，攻擊者更是不斷濫用 Log4j 漏洞，每小時都發動 1 千萬次攻擊行為。而資安與開發團隊此時還正在拚盡全力確認有漏洞的應用程式，無法即時應對威脅，結果讓漏洞濫用的風險一飛沖天。
現代應用程式是由許多開源軟體組件、套件以及微服務所結合建構而成。追蹤 Log4j套用在哪些應用程式內的複雜程度，充分說明應用程式資安防護面臨的挑戰，以及軟體物料清單（SBOM）是多麼地重要。SBOM在近年逐漸成為熱門議題。
問題是如何發生的？
自單一應用程式的時代以來，應用程式開發進程已經有許多進展。由單一公司研發的傳統單一應用程式，一般是以相同的程式語言建立，可能僅有小部分的組件是來自其他公司。如此一來，便能夠提供定義明確（通常與版權有關）的功能，例如遠端程式呼叫、資料庫連接等。這類單一模式代表單一間公司對於一個應用程式的程式碼，或多或少能夠擁有完全的可視性與掌控。
但如今，您可能得特地費一番工夫才能找到一個完全以傳統方式開發的應用程式。當今的開發人員不再建構及更新單一應用程式了，而是採用既有的程式碼（套件）與微服務來完成一般的特性與功能。比起從零開始建立，借助開源軟體（OSS）來執行應用程式中的標準工作（也就是打通應用程式的任督二脈）更有效率。如此現代應用程式的開發方式，讓開發人員能夠專注投入於讓應用程式與眾不同的方法，並創造更多商業價值。
隨著推出新應用程式的需求以及應用程式特性的增加，重複使用程式碼代碼已是必要手段。數位創新即是現代企業的競爭優勢，而這種創新正在透過應用程式呈現，且不論直接或間接，通常也是收益增長的關鍵。現在的開發團隊根本無暇建立及更新單體式應用程式。應用程式與功能推陳出新，為了趕上不斷加快的步伐，當代應用程式大多是以組塊形式建構與更新，開發人員也愈加無法擺脫對 OSS 的依賴。即便是金融或物流機構核心使用的應用程式，其中的組件如今也一樣採用了現代應用程式的開發方式，有時甚至連雲原生應用程式平台亦然。簡而言之，開源無所不在，但是各公司組織未必完全知道他們採用了哪些 OSS 組件，以及這些組件運用在應用程式的哪些地方。
問題何在？
您的機構所建構或取得的應用程式，大多都是由 OSS 所構成。事實上，根據估計，現今任何軟體的組成都有 70-90%來自免費與開源軟體，一個普通的雲端原生應用程式則差不多有 50 到 5000 個不同的組件。這表示他人建立的 OSS 以及第三方組件、相依項目，都已經整合進入您的應用程式中。一旦沒有馬上納入最新的漏洞修復套件，即使是每週更新應用程式的頻繁步調，也可能留下幾天空窗期，讓應用程式暴完全露在漏洞風險中。
問題還不僅於此。應用程式開發是一個多層的結構，直接相依項目會依賴其他相依項目，然後又會再依賴到其他相依項目，形成一軟體供應長鏈。如此龐雜的項目是幾乎不可能手動追蹤的，這使他們成為完美的攻擊媒介。
這一切的結果，就是攻擊者會針對 OSS以及第三方套件，然後就能發動大規模的供應鏈攻擊。SolarWinds 攻擊、Log4j 漏洞，以及現正發生的 NPM 攻擊，都讓全球企業對於供應鏈攻擊越來越憂心。攻擊者只要挑選廣泛使用的套件或組件為目標，居然就能順藤摸瓜，直搗核心，展開大規模攻擊。他們是如何做到的呢？
由外到內
多年來，這種方法是網路安全的準則。側重於對內的周邊，使用防火牆、端點保護、電子郵件及網站的 Gateway 和其他保護層。然而，這種保護始終不太理想，因為它將大部分資源集中在攻擊的前段，只對外部威脅具有功用。這種對外的防禦措施相對被動。尤其是這些基礎設施難管理、測量和維護，並且是由不同的單點式解決方案組成，為營運環境管理上帶來瓶頸，並提高企業風險。總而言之，這類方法只是試圖阻止入侵，而不是從各個角度提供內在保護。最佳的安全解決方案是對行動應用程式風險採取全新的策略。
了解供應鏈攻擊
想深入了解何謂軟體供應鏈攻擊，就必須先理解易受攻擊的開源套件與惡意開源套件之間的區別。開源套件中的漏洞並不少見，利用各種方式識別出漏洞後，在理想情況下，就能由可靠的披露流程進行修復，並透過通用漏洞揭露計畫 （CVE） 的消息來源、美國網路安全暨基礎設施安全局 （CISA），以及應用程式供應商自行發表，讓社群得知關於漏洞的訊息。當公司機構接獲易受攻擊套件的相關訊息後，將目前所用的版本更新至漏洞修補完畢的最新安全版本即可。然而，惡意套件就很不同了。
現在，攻擊者會操弄著開源套件與儲存庫來吸引毫無戒心的開發人員，然後進一步侵入整個組織。這些策略往往巧妙且不著痕跡，有時看起來只是套件名字不小心拼錯而已，或是在軟體自動建構的過程中有一個「新」版套件被加入基準代碼。其他的攻擊型態還會利用遺棄的儲存庫，這些儲存庫將導向惡意代碼或是偽裝成受信任實體的全新儲存庫。
近年來，許多開源儲存庫中，都已經發現了加密貨幣挖礦、勒索軟體、遠端程式碼執行、命令與控制後門程式，還有其他惡意軟體等蓄意建構的惡意套件。攻擊者透過眾多方式，像是關聯項目混淆視聽、誤植域名、供應鏈劫持、造假評語（starjacking），或甚至是類似蠕蟲病毒功能的自我傳播惡意程式，藉此將其惡意代碼散播至整個開源供應鏈。由於開源專案是以社群參與及信任為基礎，開源資料庫讓攻擊者獲得極高的投資報酬率。攻擊者能輕易利用代碼相依項目來引入惡意程式和後門程式，這使得軟體供應鏈攻擊成為熱門的攻擊媒介。因此，現在有越來越多供應鏈事件，都是因為惡意攻擊者蓄意於開源套件插入難以偵測的攻擊性程式碼所造成的。
許多業界專家都已經指出開源供應鏈「正在面臨風險」，而現代的開發與資安團隊也必須具備供應鏈攻擊、入侵威脅指標、攻擊者策略、技術與程序 （TTPs）相關的知識。這些知識至關重要，但在知識之外，開發與資安團隊也須具備相應的技術，來支援他們即時得知風險的存在，而這一切皆從了解您的軟體中究竟包含「哪些東西」開始。
SBOM 是什麼？
根據美國國家電信暨資訊管理局提出的
正式定義，SBOM 為「建構一特定軟
體時所需組件、資料庫與模組之完整並
正式建立之清單，以及其間的供應鏈關
係。該組件可為開源或具版權、免費或
付費，以及可自由取得或有存取權限。」
為未來做準備
未來會有越來越多地駭客利用使用行動應用程式的漏洞來破壞周邊安全。這些駭客不斷尋找新的方法來利用您企業的應用程式中的弱點。隨著世界潮流轉移與科技的發展，行動應用程式以成為客戶互動和商業活動的主要管道，請務必盡可能徹底地保護您的企業。請記住，安全取決於您最弱的一點 （短板理論），但透過從內到外的安全策略，您的應用程式將可以從最外層到程式進行完整保護。
SBOM 的內容，本案例為 Checkmarx SCA 所建立的 SBOM。
SBOM 可不僅僅是一張清單而已。SBOM為帶有定義屬性的產出物，必須遵循一個標準格式，並納入關於各相關組件的詳細資訊，因此在標準化的型式下用途廣泛。SBOM 至少需要提供組件的名稱、供應者名稱、版本、雜湊與其他唯一識別碼、相依關係、SBOM 資料作者，以及時間戳記。但 SBOM 的建立並非一蹴可幾，報告中還需納入每個軟體的變更及更新，以完整呈現專案的最新狀態。
誰需要 SBOM? 為什麼 ?
任何建構或部署應用程式的公司組織，不論採用雲端或本地部署，皆會因為 SBOM而獲益良多。為您的每個內部應用程式建立 SBOM，將有助於依照 OSS 與第三方組件，主動評估與了解應用程式存在的風險。您將能迅速評估哪個應用程式較易受攻擊，且倘若攻擊真的發生，便能縮短偵測耗時，並爭取應對供應鏈攻擊或 Log4j等重大資安議題所需的寶貴時間。SBOM 帶來的好處，將同時適用於您對外的應用程式以及創造收益的應用程式。為這些應用程式建立 SBOM，讓您在出現重大資安風險時能夠快速判斷哪些地方需要更新，若產品為軟體即服務形式，您便能夠即時更新應用程式，也可以向您的客戶提供修補程式或更新版本以降低風險。
另有一大可能，就是許多客戶將開始要求提供應用程式產品的 SBOM（而身為其他應用程式的使用者，您也應當如此警覺），準備對任何供應鏈攻擊迅速反應。能夠回應客戶的要求並提供 SBOM，將讓客戶對您的信任更加踏實，並也能向客戶證明您公司對資安的重視。
