開場白

今天的 D26，我們進入資安最難「看見」但最致命的一環──軟體供應鏈安全（Software Supply Chain Security）。
這並不是黑客直接攻你，而是攻擊你信任的東西：開源套件、第三方服務、CI/CD Pipeline、甚至自家更新系統。
一個被污染的套件、一把外洩的 Token，就能讓整個專案遭滲透。

目標

• 了解軟體供應鏈攻擊的鏈條與關鍵節點。
• 掌握 CI/CD 環境與相依套件的安全治理原則。
• 產出可驗收的「供應鏈風險與防禦對照表」。

主文

一、供應鏈攻擊是什麼？

定義：攻擊者利用軟體開發與分發流程中的信任關係進行滲透或竄改。

核心觀念：攻擊者不一定攻你系統，而是攻「你信任的第三方」。

二、常見風險節點

1. 套件來源不明
   • 開源套件可被上傳替代（Typosquatting、Dependency Confusion）。
   • 無版本鎖定（version pinning）導致隨更新拉入惡意版本。
2. CI/CD 平台外洩
   • CI 環境變數含 Token、金鑰或密碼。
   • 未隔離專案權限（同一 CI 用戶可讀取所有 Repository）。
3. 缺乏簽章與完整性驗證
   • 無法保證 build 產物未被竄改。
   • 缺乏 SBOM（Software Bill of Materials）。
4. 人員與流程漏洞
   • 外包、第三方整合服務權限過高。
   • 沒有雙人審核（Four-Eye Principle）導致惡意提交被混入。

三、防禦原則與具體策略

1️⃣ 相依套件治理

• 啟用 版本鎖定（Lockfile），確保可重現構建。
• 使用官方鏡像或自架私有套件庫（如 npm 私有 registry）。
• 定期執行 Dependency Audit / SCA（Software Composition Analysis）。
• 建立「允許清單（Allowlist）」與「禁止清單（Denylist）」制度。

2️⃣ CI/CD Pipeline 防護

• 把機密從 CI 腳本移除，使用**秘密管理服務（Secret Manager）**載入。
• CI 平台帳號開啟 MFA；每個 Repo 以最小權限操作。
• 使用「Ephemeral Runner」（短生命週期 Agent），避免長駐主機被竊。
• Pipeline 指令簽核制（審核後才可合併到主分支）。

3️⃣ 簽章與完整性驗證

• 建立 Code Signing（程式碼簽章） 機制：以金鑰保證產物真實性。
• 使用 Sigstore / Cosign 等工具自動簽署與驗證容器映像或建置產物。
• 發佈前比對產物 Hash 與簽章紀錄（Chain of Custody）。

4️⃣ SBOM（Software Bill of Materials）

• SBOM 是軟體元件清單，用來追蹤版本、來源、授權、風險。
• 可用工具：Syft, CycloneDX, Anchore。
• 定期產出 SBOM 並納入風險評估流程。

四、小提醒

• 「信任鏈」比「程式碼」更脆弱：攻擊者往往透過可信通道繞過所有安全檢查。
• 自動化不是安全化：CI/CD 自動化若缺乏安全節點，就成為自動感染鏈。
• 盲點在人：授權太廣的外包/機器帳號，常是滲透入口。
• 可觀測性是後盾：Log、審計與版本追蹤要能串起「誰、何時、改了什麼」。

小結

供應鏈安全不是防火牆能擋的，而是信任治理問題。
從相依套件到 CI/CD，再到發佈與簽章，每一步都可能被「借道滲透」。
落實「可追蹤、可驗證、可還原」三原則，才是面對未來開源生態的唯一防線。