💡 今日學習目標：理解 DevSecOps 的核心文化與落地心法，並看懂為什麼「有做 SCA 掃描」依然攔不住 2020 年那種等級的供應鏈攻擊。

📌 前言：攻擊者動的不是套件，是建置流程本身

2020 年 12 月，資安公司 FireEye 發現自己被入侵，一路追查回去，牽出了資安史上數一數二的供應鏈攻擊事件：SolarWinds／SUNBURST。

攻擊者滲透的不是 SolarWinds 用的某一個第三方套件，而是 SolarWinds 自己的建置（Build）流程。他們在合法簽章的 Orion 軟體更新裡，悄悄植入了一支後門 DLL。這支被動過手腳的更新，從 2020 年 3 月開始，經過官方簽章、正常上架、正常推送，一路被全球超過 18,000 個組織下載安裝，直到 2020 年 12 月才被發現。將近 9 個月，沒有人發現任何異常。

📖 資料來源：美國 CISA 資安通報 AA20-352A — Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations

這正是 Day 15 埋下的伏筆：A03 軟體供應鏈失效，範圍不只是「你引入的套件有沒有漏洞」，而是延伸到「你的建置系統、你的發布基礎設施」。SCA（Software Composition Analysis）掃描能告訴你「這個套件的某個版本有已知漏洞」，但它管不到建置流程本身被動了手腳，因為從 SCA 的角度看，那支被植入後門的 Orion.dll，就是一支「正常、簽章正確、版本號正常」的檔案。

🔍 核心理念：DevSecOps 到底改變了什麼？

在許多傳統公司裡，開發團隊（Dev）與資安團隊（Sec）像一對冤家：開發嫌資安「每次都卡關、連小問題都要停下來改」；資安嫌開發「每天只顧著搶快，出事還不是我們背鍋」。

DevSecOps（Development + Security + Operations） 想解決的正是這個對立，而它的解法不是「多開一次會」，是文化與流程的變革：

DevSecOps 三大文化轉換心法

1. 從「警察」轉型為「教練」：資安團隊不再是只會回絕 PR 的關卡，而是提供開源工具、範本與自動化管線的輔導角色，就像我們這 29 天做的事：把工具跟做法直接交到你手上。
2. Paved Road（鋪好的路）：把安全檢查嵌進工程師本來就在用的工具（IDE、CI），讓「安全的做法」剛好也是「最省力的做法」。「Paved Road」本來是 Netflix 工程文化裡的既有概念，而把它套用到資安上、講得最完整的是 Netflix Tech Blog 的 《Scaling Appsec at Netflix》。與其要求工程師記住上百條安全規範，不如把規範直接鋪進他們每天都會走的路上。
3. Clean as You Code：面對歷史遺留的龐大專案，要求「一夕之間清空所有舊債」只會讓人崩潰。應該優先要求「新寫的程式碼必須零漏洞」，門檻可持續達成，系統品質隨時間自然收斂。

🛠️ 開發團隊實踐 DevSecOps 的三大策略

策略 1：漸進式品質閘門（Incremental Quality Gates）

在 SonarQube 設定規範時採用 Clean as You Code 政策：舊程式碼給緩衝時間漸進重構，新程式碼強制實施高標準 Quality Gate（例如 Day 28 那道 Security Rating A 的門禁）。

策略 2：自動化軟體供應鏈檢查（SCA）

把套件安全檢查自動化，在 CI/CD 中自動提示有漏洞的依賴庫並給予升級建議（例如 Dependabot / Snyk）。但 SolarWinds 案例提醒我們：SCA 是必要條件，不是充分條件：它顧得到「你引入了什麼」，顧不到「你信任的供應商，建置流程本身有沒有被動手腳」。這也是為什麼 DevSecOps 談的完整性驗證，還包含建置產物的簽章驗證與來源追溯（Provenance），而不只是掃套件清單。

📋 順帶把 SBOM 講清楚：它跟 SCA 不是同一件事

Day 15 與 Day 25 都提過 SBOM，這裡補完。

SBOM（Software Bill of Materials，軟體物料清單） 是一份機器可讀的清冊，列出這一次建置到底裝進了哪些元件、哪個版本、什麼授權。目前兩個主流格式是 SPDX（已成為 ISO/IEC 5962 國際標準）與 CycloneDX（OWASP 的旗艦專案）。

跟 SCA 最容易混淆，但兩者的性質完全不同：

差別在哪裡？看 2021 年 12 月的 Log4Shell（CVE-2021-44228）就懂了。 漏洞公布的那個週末，全世界無數團隊做的第一件事不是修補，而是先找出「我們到底哪裡用到了 log4j」，而且很多公司花了好幾週才問完這個問題。

有 SBOM 的團隊，這一題是查詢，不是調查。 因為關鍵不在於「今天掃出什麼」，而在於明天冒出一個新的 CVE 時，你能不能在十分鐘內說出哪些版本、哪些服務受影響。SCA 只能告訴你掃描當下的答案；SBOM 讓你有辦法回頭查每一次建置。

免費工具很成熟，挑一個接進 CI 就好：Syft、OWASP cdxgen、Trivy 都能對原始碼或容器映像檔直接產生 SBOM，docker sbom 與 npm 內建的 npm sbom 也可以。產出的檔案要跟著建置產物一起歸檔，不然它只是一次性的報告，失去了回溯的價值。

🔑 這件事正在從「加分項」變成「門檻」。 美國 2021 年的第 14028 號行政命令，已經要求賣給聯邦政府的軟體必須附上 SBOM；歐盟的網路韌性法案（CRA）也把類似要求納入。如果你的產品有機會賣進這些市場，這一項遲早會出現在採購合約裡。

策略 3：安全設計模式標準化（Security Paved Road）

由資安與資深工程師共同封裝出安全的基底庫與 Framework（例如自動加鹽 Hash 的 Auth 模組、內建參數化查詢的 ORM 底層），新進工程師直接呼叫這套「黃金道路」，連犯錯寫出漏洞的機會都沒有。

🧭 進階延伸：如果你想再往下挖建置完整性

SolarWinds 事件之後，業界確實有在補這塊拼圖。OpenSSF（Open Source Security Foundation）提出了 SLSA（Supply-chain Levels for Software Artifacts） 框架，核心精神是：不只驗證「這個套件本身」，還要能驗證「這個套件是從哪一份原始碼、經過哪一條建置流程、由誰簽署後產生的」，也就是幫每一次建置產出留下一份可驗證的「出生證明」（Provenance）。

這已經超出一般開發者日常會直接動手的範圍，但知道它的存在很重要：當你未來評估要不要導入某個 CI/CD 平台或套件註冊表時，「是否支援 SLSA / 建置來源驗證」會是一個值得問的問題。

⚠️ 迷思破解：「我們有做 SCA 掃描，供應鏈就安全了」

這是 DevSecOps 導入過程中最常見的錯覺。SCA 掃描確實重要，它能抓到「已知漏洞的舊版套件」這種最常見的供應鏈問題。但 SolarWinds 告訴我們，真正頂級的供應鏈攻擊，鎖定的往往不是你掃得到的地方，而是你預設信任、從來不會去掃的地方：官方簽章的更新檔、受信任廠商的建置伺服器。

這不是要你放棄 SCA（它依然是性價比最高的第一道防線），而是提醒你：供應鏈安全是一個縱深防禦問題，不是裝一個掃描工具就能打勾收工的 checklist 項目。

🎯 今日重點小結與防守心法

• 🔹 心法 1：速度與安全可以兼得。透過自動化管道讓資安無縫融入開發，而不是事後阻擋。
• 🔹 心法 2：SCA 是起點，不是終點。它抓得到已知漏洞的套件，抓不到被動過手腳的建置流程。
• 🔹 心法 3：把安全鋪成一條路，而不是立成一道牆。Paved Road 讓「照著做」自然而然變成最省力的選擇。

💬 明日預告：【Day 30】鐵人賽完賽結語：從資安新手到打造個人防守線，你的資安旅程才剛開始！
明天，我們一起回顧這 30 天走過的路，也一起把「駭客只需要成功一次」這句話，做一次最後的收尾。