在現代軟體開發中，我們習慣於依賴大量的開源套件。大多數工程師的直覺是，只要這個套件知名度高、維護者有聲望，它就是安全的。然而，curl 的創始人 Daniel Stenberg 最近提出了一個關鍵警訊：在軟體供應鏈安全中，預設信任知名元件的作法已經不再足夠，我們必須將信任轉化為可驗證的流程。
為什麼信任不再可靠
對於像 curl 這樣部署在數十億台設備上的基礎元件，其成為攻擊目標的價值極高。Stenberg 指出，即使維護團隊盡全力投入，依然存在多種被滲透的風險。例如，一名惡意的貢獻者可能透過長期經營信任來植入後門，或者維護者的帳號被盜用導致發布被篡改的版本，甚至是發布伺服器被駭客入侵，將原本正常的安裝檔替換成含有惡意代碼的檔案。
這種風險在 2024 年的 XZ Utils 後門事件中得到了印證。當時攻擊者採取了長期的社交工程，逐步贏得維護者的信任並獲得提交權限，最終植入後門。這證明了單靠聲望或信任關係，無法阻止有計畫的供應鏈攻擊。
建立可驗證的開發流程
為了降低風險，curl 採取了一套極其嚴格的內部控制措施，目的是讓 Git 儲存庫成為唯一且可審計的真理來源。
首先是代碼層級的管控。curl 強制執行統一的代碼風格，禁止使用容易導致安全漏洞的 C 語言函數，並對函數的複雜度設定上限。此外，所有提交必須經過人工與自動化審查，且嚴格禁止在代碼中包含二進位大對象（Binary Blobs）或大部分的 Base64 編碼內容，因為這些格式最容易被用來隱藏惡意載荷。
其次是自動化與基礎設施的防禦。curl 在每次提交時會執行超過 200 個 CI 任務，並使用最嚴格的編譯器設定，將所有警告視為錯誤。同時利用 Google 的 OSS-Fuzz 進行持續模糊測試（Fuzzing，一種透過輸入隨機數據來尋找崩潰點的測試方法），並要求所有維護者必須開啟二階段驗證（2FA）。
對外部使用者而言，curl 提供了簽署後的發布產出（Signed Release Artefacts）以及詳細的驗證指南。這讓使用者可以獨立確認下載的版本是否僅包含 Git 儲存庫中的代碼，且確實是由發布經理簽署的。
軟體物料清單 SBOM 與合規壓力
除了個案的實踐，業界正推動一種結構化的標準稱為 SBOM（Software Bill of Materials），即軟體物料清單。簡單來說，SBOM 就像是軟體的成分表，詳細列出該軟體包含的所有依賴元件及其版本。
隨著歐盟《網路韌性法案》（Cyber Resilience Act）等法規的推行，提供 SBOM 已不再是可選項，而將成為進入市場的強制要求。然而，單純產生一份清單是不夠的，關鍵在於簽署（Signing）。如果 SBOM 沒有經過數位簽署，它就無法證明在傳輸過程中沒有被篡改。因此，在 CI/CD 流程中自動化簽署 SBOM，建立可驗證的監管鏈（Chain of Custody），才是確保供應鏈安全的正確做法。
工程實務的建議
對於開發者與企業，應將安全重心從信任移向驗證。在實務操作上，可以參考以下方向：
第一，對依賴項進行嚴格管控。不要僅依賴版本號，應儘量將依賴項固定到特定的提交雜湊值（Commit Hash），以避免上游版本被靜默篡改。
第二，審視 CI/CD 管道的安全性。許多專案使用第三方 GitHub Actions，但這些 Action 若被攻破，可能會洩露金鑰或篡改構建產出。應限制 CI 任務的權限（例如設定為唯讀），並使用工具檢查 Job 配置是否安全。
第三，建立驗證習慣。如果上游套件提供了簽名或校驗碼，應將驗證步驟納入部署流程中，而非直接信任下載的檔案。
總結來說，軟體安全不應建立在對人的信任上，而應建立在可重複、可審計的驗證機制上。當我們能夠驗證每一行進入系統的代碼來源時，才能真正降低供應鏈被滲透的風險。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。