💡 先搞懂問題
很多團隊的開發流程長這樣：先談需求、畫設計、埋頭寫程式，等功能都做完、快要上線了，才請資安人員「掃一下」。這時如果掃出來的只是某一行程式寫得不好，改一改還來得及；但如果發現的是設計上的根本問題，例如整個系統根本沒有區分一般使用者和管理者的權限，那就不是改一行程式的事，而是要回頭重新設計、重寫、重測，上線日期只能往後延。更糟的情況是沒被發現就上線了，最後由攻擊者替你找到，代價變成緊急修補、資料外洩通報與商譽損失。
還有一個常被忽略的問題：現代軟體裡，自己寫的程式碼往往只占一小部分，其餘大量來自開源套件與第三方元件。就算自家程式寫得很小心，只要引用的某個套件出現漏洞，產品一樣會被拖下水；而且當漏洞公布時，很多公司連「我們哪些產品用到這個套件」都答不出來。
用裝潢一間房子來想
裝潢時，插座要裝在哪裡，在畫設計圖的階段決定，改的成本只是擦掉重畫；如果等到牆面封好、油漆上完才發現插座不夠，就得敲牆重拉線；搬進去住以後才改，除了敲牆，還得搬家具、忍受噪音和灰塵。所以有經驗的屋主會在每個階段各做一次檢查：設計時先想好動線與用電，施工時請監工看管線有沒有照圖走，完工時實際開關每個水龍頭和電燈，並且保留每批建材的出廠證明，萬一日後某批電線被召回，翻一下清單就知道自己家有沒有用到。
回到資安，這個裝潢故事對應的就是安全開發生命週期（Secure SDLC，Secure Software Development Life Cycle）：把資安工作拆進軟體開發的每個階段，而不是集中在最後。把資安活動盡量往流程前端（時間軸的左邊）移，就叫左移（Shift Left）。
比喻的限制：房子蓋好後大致就固定了，軟體卻會持續改版；而且即使一行程式都沒改，某個引用的套件也可能某天突然被公布漏洞。所以軟體的「維運」不是收尾，而是持續監控、持續修補的常態工作，這一點和裝潢很不一樣。
🎮 互動實驗室 1：SDLC 流水線，把資安活動放到對的階段先看流程逐步播放，再親手把 14 張資安活動卡分配到各階段
先把軟體開發切成六段：需求、設計、開發、測試、部署、維運。微軟把這套「每段都有資安活動」的做法整理成 SDL（Security Development Lifecycle，安全開發生命週期），階段名稱略有不同，圖上方框下的小字就是對應的 SDL 階段。按「▶ 下一步」，看一個新功能從需求一路走到維運，每一站要做哪些資安工作。
換你動手：把活動卡放進正確階段
拖曳下方的卡片到階段格子裡；手機上也可以先點一張卡片，再點要放的階段。放錯時卡片會彈回來，並告訴你為什麼。
🎮 互動實驗室 2：越晚修越貴拖動滑桿，看同一個問題在不同階段被發現，要付出多少代價
「越早修越便宜」不是口號，而是因為越後面的階段，已經有越多東西建立在這個錯誤之上：程式寫好了、測試跑過了、系統上線了、客戶資料也進來了。修一個問題的成本，包含的不只是改程式，還有重測、延後上線、通報與商譽損失。先選一種問題，再拖動滑桿決定它在哪個階段被發現。
整個專案算一次：傳統做法 vs 左移
假設一個專案一共埋了 20 個安全問題（示意）。傳統做法幾乎都在測試或上線後才發現；左移做法則在需求、設計、開發時就攔下大部分。用上面的倍數算總帳：
🎮 互動實驗室 3：SAST、DAST、IAST、SCA 該派誰上場先看四種工具各看得到哪裡，再挑戰 8 個情境
檢測工具最常被搞混的，是它們「看的東西」不一樣。有的看程式碼本身，有的把系統跑起來從外面戳，有的鑽進執行中的程式裡觀察，有的只清點你引用了哪些別人寫的套件。點下方四個工具，看它們在圖上各自對準哪裡。
情境挑戰
🎮 互動實驗室 4：模糊測試，對一個欄位亂丟輸入純頁內模擬，目標是一段虛構的日期解析程式
測試人員寫測試案例時，通常只會想到「正常的輸入」和幾種「常見的錯誤輸入」。但程式當掉，往往是因為某個沒人想到的怪輸入：空字串、超長字串、奇怪的字元、格式幾乎正確只差一點點。模糊測試（Fuzzing）的做法是讓程式自動產生大量畸形或隨機的輸入，一筆一筆餵給目標程式，同時由監控器盯著程式有沒有當掉、卡住，並把造成問題的輸入記錄下來，讓開發者重現與修補。
下面的目標是一個虛構預約系統的「出生日期」欄位，預期格式是 YYYY-MM-DD。這段程式裡藏了 5 個會讓它當掉或卡住的錯誤，試著用兩種模糊測試策略把它們找出來，也可以自己手動輸入試試看。
| # | 送出的輸入 | 結果 |
|---|
🎮 互動實驗室 5：漏洞公告來了，用 SBOM 查受影響產品一家虛構公司的三個產品、虛構的元件與漏洞公告
2021 年底 Log4j 日誌套件爆出 Log4Shell 漏洞（CVE-2021-44228）時，許多公司最頭痛的不是怎麼修，而是「我們到底哪些系統有用到它」。因為這個套件常常不是直接被引用，而是藏在別的套件裡面，屬於間接相依（transitive dependency）。SBOM（Software Bill of Materials，軟體物料清單）就是事先把每個產品用了哪些元件、什麼版本、誰引用誰，整理成機器可讀的清單，漏洞公布時直接查詢。
下面是一家虛構公司的三個產品，元件名稱與漏洞公告都是虛構的。選一則公告，比較「有 SBOM 直接查」和「沒有 SBOM、請各團隊自己回想」的差別。
① 選一則漏洞公告（虛構）
② 用哪種方式查
SBOM 長什麼樣子
SBOM 有標準格式，常見的是 SPDX（由 Linux 基金會主導，已成為國際標準 ISO/IEC 5962）與 CycloneDX（由 OWASP 社群發起），都能輸出成 JSON 等機器可讀格式，讓工具自動比對漏洞資料庫。下面是這三個產品 SBOM 的簡化示意（以 CycloneDX 風格呈現，欄位經過刪減），可以切換產品，公告命中的元件會標成紅色。注意它記錄的是「用了什麼」，不是程式執行時做了什麼。
📘 原理補完
SDLC、SDL 與相關標準
SDLC（Software Development Life Cycle）是一般的軟體開發生命週期，只描述開發要經過哪些階段；SDL 是微軟把資安活動嵌進每個階段的具體做法，經典版本分成七個階段：訓練、需求、設計、實作、驗證、發行、回應。考試常問某個活動屬於哪個階段，最常見的三組是：縮小攻擊面屬設計、靜態分析屬實作、模糊測試屬驗證，而發行前要完成最終安全審查並備妥事件回應計畫。實驗室 1 的六階段只是把「訓練＋需求」合併、把「發行」稱為部署。
其他常被提到的框架包括：專談應用程式安全的國際標準 ISO/IEC 27034，以及美國 NIST 的安全軟體開發框架 SSDF（SP 800-218），它規範整個開發流程該做哪些安全實務，包括第三方元件的管理。上線後的系統變更要走正式的變更控制程序；作業系統、資料庫、中介軟體等平台變更後，關鍵應用程式也要重新審查與測試，因為底層改變可能讓原本安全的程式出現新問題。
左移與 DevSecOps：把檢查變成管線上的關卡
左移講的是「早一點做」，但光靠人記得去做並不可靠。DevSecOps 的想法是把安全檢測自動化地放進持續整合與持續部署（CI/CD）的管線裡，每次提交、每次建置都自動執行；發現嚴重問題時，管線就停下來不讓它往下走，就像生產線上的品管關卡。點下圖每一站，看看各站常放哪些安全檢查。
白箱、黑箱、灰箱：測試者知道多少
這三個詞描述的是「測試者對系統內部知道多少」。白箱測試（White-box）拿得到原始碼與設計文件，可以有系統地檢查內部邏輯，原始碼檢測與 SAST 都屬這一類；黑箱測試（Black-box）不看內部，只能像使用者或攻擊者一樣從外部輸入、觀察輸出，DAST 與一般的滲透測試屬這一類，較容易發現部署之後才出現的問題；灰箱測試（Gray-box）介於中間，例如拿到部分文件或一般使用者帳號，IAST 常被歸在這裡。
四種工具逐項比較
把實驗室 3 的四種工具放在一起比，考試最常問的是三件事：什麼時候執行、需不需要原始碼、誤報多不多。
| 方法 | 看什麼 | 何時執行 | 需要原始碼？ | 誤報 | 看不到什麼 |
|---|---|---|---|---|---|
| SAST 靜態／白箱 | 自家原始碼（或位元碼） | 開發中：寫程式、提交、建置時 | 需要 | 較多，工具不知道實際執行情境 | 部署組態錯誤、執行期的授權邏輯、第三方套件的已知漏洞 |
| DAST 動態／黑箱 | 執行中的系統，從外部送請求 | 系統能執行後：測試環境、上線前後 | 不需要 | 相對較少，但仍需人工確認 | 沒爬到的功能；也無法指出是哪一行程式 |
| IAST 互動式／灰箱 | 執行中系統的內部資料流 | 功能測試或 DAST 進行時 | 不必交給工具掃描，但要在執行環境裝代理程式 | 通常較低 | 測試沒跑到的程式路徑；不支援的語言或平台 |
| SCA 軟體組成分析 | 第三方與開源元件、版本、授權 | 開發與建置時，上線後持續監控 | 要相依清單或建置產物，不分析自家程式邏輯 | 版本命中不代表一定能被利用 | 自家程式的缺陷、尚未公開的漏洞 |
工具歸類也是常考題：Fortify、Checkmarx、SonarQube 是原始碼檢測（SAST）工具；Burp Suite、OWASP ZAP 是網頁測試代理，常用來做 DAST 與手動網頁測試；Nessus、OpenVAS 是弱點掃描器，主要掃主機與服務的已知弱點；Chef 是組態管理工具，和檢測無關。DAST 和滲透測試也要分清楚：DAST 是自動化掃描，滲透測試由專人在授權範圍內串起攻擊鏈、驗證實際影響，兩者的差別可以看弱掃、滲透測試與紅隊演練那一頁。自動化工具不懂業務邏輯又有誤報，所以實務上會把源碼檢測和滲透測試的結果互相對照，覆蓋率和準確度都比只做一種好。
程式碼審查與模糊測試
程式碼審查（Code Review）是由其他開發者在程式合併前閱讀並討論變更，常搭配檢查清單，例如輸入有沒有驗證、錯誤訊息會不會洩漏內部資訊、有沒有寫死的密碼。它能看懂工具看不懂的業務邏輯，但很花時間，也受審查者經驗影響，所以通常和 SAST 並用：工具負責大量、重複的模式比對，人負責判斷邏輯與設計。另外要注意，原始碼掃描抓的是常見的寫法缺陷，對刻意隱藏的惡意程式碼（後門）不一定有效。
模糊測試回到實驗室 4 的畫面：產生器依策略造出輸入，可以是純隨機、以正常樣本突變（mutation-based），或依照格式規則產生（generation-based）；較進階的工具還會觀察哪些輸入走到了新的程式路徑（覆蓋率導向），優先拿它們繼續突變。監控器負責判斷當機、逾時與記憶體錯誤，並保存觸發輸入。它擅長找出輸入處理的缺陷，像緩衝區溢位、未處理的例外、無窮迴圈；但它找的是「會出事的輸入」，不會告訴你授權邏輯對不對，也不能證明程式沒有漏洞。常見的誤解是把模糊測試當成「自動產生程式碼插進原始程式」，其實它是把錯誤格式或混亂的資料餵給程式。
軟體供應鏈：SCA、SBOM 與元件管理
回到裝潢比喻裡的「建材出廠證明」：SCA 是工具，SBOM 是清單。SCA 分析專案實際引用的元件，比對已知漏洞與授權；SBOM 則是把元件名稱、版本、供應者、相依關係、授權等資訊整理成標準格式（SPDX、CycloneDX）的清單，SCA 工具常能直接產出它。美國 NTIA 提出的 SBOM 最低要素包括供應者名稱、元件名稱、版本、其他唯一識別碼、相依關係、SBOM 資料的作者與時間戳記。
SBOM 的限制也要記清楚：它記錄的是組成，不是程式執行時的行為；它本身不會修補任何東西，價值在於漏洞公布時能快速「識別」受影響範圍，所以在 NIST CSF 中對應的是識別功能。要發揮效果，清單必須完整、可查詢、跟著每次發行更新，並持續與弱點資訊比對。元件管理的原則包括：只從官方或可信來源取得元件、評估元件是否仍有人維護、定期更新並移除用不到的元件；只確認下載來源而不持續追蹤漏洞並不夠。外部套件進入建置前，也可以先經過私有套件庫與隔離觀察期，攔下被植入惡意程式的版本，這類惡意套件是 SAST 看不到的，因為它不在自家原始碼裡。
委外開發也是供應鏈的一環：外包廠商的安全要求應與自行開發一致，契約中要約定原始碼與智慧財產權歸屬、驗收測試與稽核權利；外部交付的軟硬體即使來自知名廠商，上線前也要先驗證測試。AI 工具或委外產出的程式碼同樣可能帶有漏洞，合理的處理方式是納入 CI/CD 的安全測試，而不是一律禁止或完全不檢查。
簽章與完整性：確認拿到的就是原廠那一份
就算元件本身沒問題，檔案在傳遞途中也可能被調包。雜湊值（例如 SHA-256）可以檢查檔案有沒有被改過，但它只能證明「和公布的值一樣」；如果攻擊者能同時換掉檔案和網站上公布的雜湊值，只比對雜湊就會被騙。數位簽章用發行者的私鑰簽署，使用者用公鑰驗證，同時確認來源與完整性，攻擊者沒有私鑰就偽造不出有效簽章。但如果連建置環境本身都被入侵，惡意程式在簽章之前就被植入，簽章照樣有效，這時要靠 SLSA 這類著重建置完整性的框架：在隔離、短暫的環境建置，由建置服務產生並簽署來源證明（Provenance），並把建置腳本納入版本控制與審查。切換下面的情境看看各種防護在哪裡生效。
容易混淆的幾組
網頁應用最常見的十大風險（包含「易受攻擊與過時的元件」與「軟體與資料完整性失效」）整理在 OWASP Top 10 那一頁；注入、XSS 等攻擊手法的原理則在網頁攻擊手法那一頁。
✅ 自我檢測6 題情境題，按下選項立即顯示對錯與解析
目前答對 0 / 6
🎯 重點整理考前 30 秒版
- 安全開發生命週期把資安活動拆進需求、設計、開發、測試、部署、維運；同一個問題越晚發現越貴，上線維運階段修正成本最高，需求與設計階段最低。
- SDL 階段歸類：威脅建模與縮小攻擊面屬設計、靜態分析屬實作、模糊測試屬驗證、發行前要最終安全審查並備妥事件回應計畫。
- DevSecOps 把檢測自動化放進 CI/CD，未通過就擋下；最適合左移進管線的是 SAST。
- SAST 看自家原始碼、開發中就能跑、誤報較多；DAST 不需原始碼、測執行中系統、較能抓部署與組態問題；IAST 在執行中系統內裝探針、誤報較低；SCA 查第三方套件的已知漏洞與授權。
- 白箱看得到內部，黑箱只看輸入輸出，灰箱介於中間；DAST 是自動化掃描，滲透測試由人工驗證弱點能否被利用。
- 模糊測試是把大量畸形或隨機輸入餵給程式並監控當機，不是把程式碼插進原始程式，也無法證明沒有漏洞。
- SCA 是工具、SBOM 是清單（SPDX、CycloneDX）；SBOM 記錄組成而非執行行為，本身不修補；簽章確認來源與完整性，建置過程可信要靠 SLSA。