供應鏈上的信任

一個銀行 IT 工程師的實作紀錄

作者

Ryan Chen

发布于

2026年8月26日

前言：一個銀行 IT 為什麼寫供應鏈信任

我在某金融機構做 IT。銀行的日常是治理、稽核、變更管理——我們對「一支程式怎麼上線」有一整套流程。但有一天我意識到一件不舒服的事：流程管的是「我們自己寫的那幾千行」，而系統裡真正在跑的，是幾十萬行別人寫的依賴（dependency）。那些程式碼從哪來、有沒有被動過手腳、憑什麼相信它—— 我答不出來。

與其再抄一份「供應鏈安全 checklist」，我決定做一件笨但徹底的事：從最底層的密碼學原語（primitive，最小构件）開始，把「信任」這個東西一層一層親手搭起來——簽章是什麼、憑證憑什麼可信、加密和簽章合用時會怎麼出事——然後才把這些原語套到軟體供應鏈上，看清楚 SBOM、成品簽章、provenance（來源證明）那些流行詞底下，到底是哪幾塊積木在承重。

這本書記錄的就是這趟旅程。

這本書寫給誰

讀之前先對齊期待

這本書寫給：

後端 / 平台 / DevOps 工程師，天天在 npm install、mvn package、拉 container image，但沒想過（或不敢想）這條鏈上每一步憑什麼可信；
資安、稽核、治理背景的人，看得懂「控制」但想搞懂控制底下的密碼學機制到底保證了什麼、沒保證什麼；
跟我一樣的 Java 工程師：書裡的類比與程式碼多用 Java（Signature、keystore、cacerts），那是我的母語，也可能是你的。

你需要先會：能讀懂一段中等長度的程式碼（任何語言）、會用命令列。不需要密碼學背景—— 需要的心智模型這本書會邊走邊建，而且刻意避開數學推導，只留「為什麼是這個方向」的直覺。

這本書的主線

有一句話貫穿全書，請你邊讀邊抓著它：

信任不是被「算」出來的，是被「授予」的。 密碼學只負責把「人為的信任決定」用數學固定下來——讓它可驗證、防竄改、能傳遞。

第一部（本卷）把三個原語搭起來：hash（雜湊）、數位簽章、MAC（訊息鑑別碼）。第二部（撰寫中）把它們套到軟體供應鏈：從 NIST SSDF 的要求，到 CI/CD 裡真的把成品簽起來。

另一條紀律借自我上一本書：先預測 → 實測 → 為什麼。每章遇到關鍵結論前，我會先請你停下來猜；能動手的地方就給你可跑的腳本（examples/），例如簽一個檔案、改一個 byte、親眼看驗章失敗。猜錯的地方才是真正學到東西的地方。

三條閱讀路徑

路徑	適合誰	怎麼走
🟢 10 分鐘速覽	想先知道這本書值不值得讀	只讀序章（第 1 章）＋每章結尾的「本章帶走的東西」
🟡 完整旅程	想把心智模型真的建起來	照章節順序讀，遇到「先猜」就真的停下來猜，`examples/` 跑起來
🔵 借 pattern	手上有具體問題（要簽 artifact、要驗憑證鏈）	直接跳第 5 章的「三原語能力邊界」表定位問題，再回讀對應章

第 4 章（認證加密）標註了「深入，可略讀」——它解釋的攻擊很精彩，但第一次讀跳過不影響主線。

誠實邊界

這本書是什麼、不是什麼

這是學習與作品集，不是產品，也不是你環境的安全設計依據。書裡的結論我盡力驗證過，但請帶著懷疑讀——這正是本書想教的態度。
所有場景描述一律寫「某金融機構」或「典型銀行環境」，資料已去識別：書中不含任何真實組織名、內部系統、金鑰或設定。
我不是密碼學家。我是一個把「不懂」誠實寫出來、再一步步補起來的工程師。數學層面的嚴格證明請讀原始論文（參考文獻附上）。

# 前言：一個銀行 IT 為什麼寫供應鏈信任 {.unnumbered} 我在某金融機構做 IT。銀行的日常是治理、稽核、變更管理——我們對「一支程式怎麼上線」有一整套流程。但有一天我意識到一件不舒服的事：**流程管的是「我們自己寫的那幾千行」，而系統裡真正在跑的，是幾十萬行別人寫的依賴（dependency）。**那些程式碼從哪來、有沒有被動過手腳、憑什麼相信它—— 我答不出來。與其再抄一份「供應鏈安全 checklist」，我決定做一件笨但徹底的事：**從最底層的密碼學原語（primitive，最小构件）開始，把「信任」這個東西一層一層親手搭起來**——簽章是什麼、憑證憑什麼可信、加密和簽章合用時會怎麼出事——然後才把這些原語套到軟體供應鏈上，看清楚 SBOM、成品簽章、provenance（來源證明）那些流行詞底下，到底是哪幾塊積木在承重。這本書記錄的就是這趟旅程。 ## 這本書寫給誰 ::: {.callout-note} ## 讀之前先對齊期待 **這本書寫給**： - **後端 / 平台 / DevOps 工程師**，天天在 `npm install`、`mvn package`、拉 container image，但沒想過（或不敢想）這條鏈上每一步憑什麼可信； - **資安、稽核、治理背景的人**，看得懂「控制」但想搞懂控制底下的密碼學機制到底保證了什麼、 **沒**保證什麼； - **跟我一樣的 Java 工程師**：書裡的類比與程式碼多用 Java（`Signature`、keystore、`cacerts`），那是我的母語，也可能是你的。 **你需要先會**：能讀懂一段中等長度的程式碼（任何語言）、會用命令列。**不需要**密碼學背景—— 需要的心智模型這本書會邊走邊建，而且刻意避開數學推導，只留「為什麼是這個方向」的直覺。 ::: ## 這本書的主線有一句話貫穿全書，請你邊讀邊抓著它： > **信任不是被「算」出來的，是被「授予」的。** > 密碼學只負責把「人為的信任決定」用數學固定下來——讓它可驗證、防竄改、能傳遞。第一部（本卷）把三個原語搭起來：hash（雜湊）、數位簽章、MAC（訊息鑑別碼）。第二部（撰寫中）把它們套到軟體供應鏈：從 NIST SSDF 的要求，到 CI/CD 裡真的把成品簽起來。另一條紀律借自我上一本書：**先預測 → 實測 → 為什麼。**每章遇到關鍵結論前，我會先請你停下來猜；能動手的地方就給你可跑的腳本（`examples/`），例如簽一個檔案、改一個 byte、親眼看驗章失敗。猜錯的地方才是真正學到東西的地方。 ## 三條閱讀路徑 | 路徑 | 適合誰 | 怎麼走 | |---|---|---| | 🟢 **10 分鐘速覽** | 想先知道這本書值不值得讀 | 只讀序章（第 1 章）＋每章結尾的「本章帶走的東西」 | | 🟡 **完整旅程** | 想把心智模型真的建起來 | 照章節順序讀，遇到「先猜」就真的停下來猜，`examples/` 跑起來 | | 🔵 **借 pattern** | 手上有具體問題（要簽 artifact、要驗憑證鏈） | 直接跳第 5 章的「三原語能力邊界」表定位問題，再回讀對應章 | 第 4 章（認證加密）標註了「深入，可略讀」——它解釋的攻擊很精彩，但第一次讀跳過不影響主線。 ## 誠實邊界 ::: {.callout-important} ## 這本書是什麼、不是什麼 - 這是**學習與作品集**，不是產品，也不是你環境的安全設計依據。書裡的結論我盡力驗證過，但請帶著懷疑讀——這正是本書想教的態度。 - 所有場景描述一律寫「某金融機構」或「典型銀行環境」，**資料已去識別**：書中不含任何真實組織名、內部系統、金鑰或設定。 - 我不是密碼學家。我是一個把「不懂」誠實寫出來、再一步步補起來的工程師。數學層面的嚴格證明請讀原始論文（參考文獻附上）。 :::