AI 把一個功能的開發生命週期壓縮成一個下午，被壓掉的正好是安全檢查的機會。
小安不是工程師，但他用 AI 花了兩個週末，做出一個讓朋友預約攝影時段的網站。登入、預約、付訂金、後台管理都有。朋友介紹朋友，一個月後有兩百多個人在用。
某天早上，他收到一封陌生人寄來的信：「你的網站可以看到所有人的電話和預約紀錄，建議你修一下。」同一週，AI API 的帳單比上個月多了一個零。
小安很困惑。他每個功能都測過，全部都能用。
他測的是「功能能不能用」，沒有人測「不該發生的事會不會發生」。
你跟 AI 說「幫我做一個預約網站」，AI 會做出一個能預約的網站。這是它的目標，它也做到了。
但你沒說的事情，例如：
這些「不該發生的事」，AI 有時會幫你補上，有時不會。最麻煩的是：你不會知道它補了沒有。
我接過一個救援案。前一位工程師大量用 GPT 協助開發，需求來了就丟給 AI，程式碼出來、貼上、能跑、收工，前期進度快得驚人。
我打開 codebase，到處都是 AI 建議的痕跡。每一段程式碼都是針對「當下這個功能」的解法，單獨看都能跑；拼在一起，卻從來沒有人站在整個系統的角度過濾過。外表光鮮，內部管線亂接。我花了兩個月收尾，業主除了多付預算，還賠上半年的開發時間。
那兩個月我做的事，就是補上一層濾網。
AI 會把眼前這個功能做到能跑，但不會替整個系統想邊界在哪裡。安全問題就藏在這種地方：一個沒有人看過全貌的系統，也不會有人知道哪裡少了一道檢查。
類似的事也出現在公開案例裡，2025 年就有兩件：
這兩件事卡在開發流程的不同位置（後面會講這條流程叫 SSDLC）：Lovable 的問題在設計時就決定了（資料庫直接開給前端，這個系列第 5 天會談），Replit 的問題在維運（agent 碰得到正式環境，第 26 天會談）。
不管 AI 用什麼技術幫你做，服務都可以拆成四塊：
| 區塊 | 在哪裡執行 | 誰能控制 |
|---|---|---|
| 前端（你看到的畫面） | 使用者的瀏覽器或手機 | 使用者，他可以任意修改 |
| 後端（處理請求的程式） | 你的伺服器或雲端平台 | 你 |
| 資料庫 | 雲端資料庫服務 | 你，前提是權限設對 |
| 第三方服務（AI、簡訊、金流） | 別人的伺服器 | 拿到 API key 的人 |
這週你只要記住一條規則：
前端的一切都可以被改，保護只能放在後端和資料庫。
軟體開發有一條生命週期（SDLC）：決定要做什麼、設計、寫程式、測試、上線、維護。SSDLC（Secure Software Development Life Cycle）的意思是：在每一個階段，都放進對應的安全活動，而不是等上線後才補。
用 AI 開發時，一個功能從想法到上線，常常一個下午就跑完一輪。小安那兩個週末，就是一個接一個這樣的下午。問題是，每一輪被壓掉的，正好是安全活動：
| SSDLC 階段 | 傳統開發 | 用 AI 開發時實際發生的事 | 被跳過的安全活動 |
|---|---|---|---|
| 需求與設計 | 規格書、架構審查 | 第一句提示詞，AI 自己決定架構 | abuse case、threat modeling、權限表、信任邊界 |
| 實作 | 工程師寫 | agent 寫 | 管好寫程式的 AI，也管好 AI 寫出的程式 |
| 驗證 | 測試、code review | 「點點看，能動」 | 越權測試、依賴檢查、安全測試 |
| 發布與維運 | 部署流程、監控 | 按下 Deploy | 設定檢查、環境分離、費用上限與警示 |
| 回應 | 事件處理流程 | 沒有 | 撤銷、通知、追查影響範圍、事後檢討 |
用 AI 開發時，「實作」這個階段有兩個攻擊面：
所以這個系列把實作拆成兩週。
每週對應一個 SSDLC 階段，每一篇文章都是這條主幹上的一段：
| 週 | SSDLC 階段 | 這週回答的問題 |
|---|---|---|
| 1 | 需求與設計 | 寫第一句提示詞之前，要先想清楚什麼？ |
| 2 | 實作①：管好寫程式的 AI | 讓 agent 動手之前，它的工作環境安全嗎？ |
| 3 | 實作②：管好 AI 寫出的程式 | AI 最常在哪幾類功能上出錯？ |
| 4 | 驗證 | 怎麼證明它是安全的，而且之後不會壞掉？ |
| 5 | 發布、維運與回應 | 上線前檢查什麼？出事時第一個小時做什麼？ |
SSDLC 決定什麼時候做。另外還有五個思考模型，決定做的時候問什麼：信任邊界、身分與權限、資料被當成程式執行、狀態與時間、預設值與依賴。明天會詳細介紹，之後每一篇的開頭都會標出這篇在哪個階段、用到哪個思考模型；結尾的「攔截點」會告訴你，這個問題最早該在哪個階段被攔下。
每週最後一天是實戰題，用一個由 AI 生成的靶場（專門拿來練習找漏洞、只在自己電腦上跑的服務）動手做一次。
每一篇都從情境開始，接著是不用看程式碼就能做的檢查和提示詞，再往下才是機制、程式碼、測試與標準。
看不懂的地方先跳過，不影響你做前半段的檢查。今天看不懂的程式碼，等你的服務長大，或是第二次回來翻的時候，可能就看得懂了。這個系列是寫來反覆查的，讀一次記不住很正常。
你能回答這四個問題嗎？
答不出來沒關係，先把答不出來的那幾題記下來，這週就從那裡開始查。
請用不懂程式的人看得懂的方式，說明這個專案的架構：
1. 哪些程式在使用者的瀏覽器執行、哪些在伺服器執行
2. 資料存在哪裡，用的是什麼服務
3. 用了哪些第三方服務，它們的 API key 或密碼放在哪個檔案
4. 每一個區塊標出「使用者可以修改」或「只有伺服器能控制」
只要說明，不要修改任何程式碼。每一點都附上對應的檔案位置。
怎麼確認 AI 說的是真的：
SSDLC 不是這個系列發明的框架。五週的切法主要參考兩份標準。
Microsoft SDL（Security Development Lifecycle）有五個核心階段：requirements、design、implementation、verification、release；前後再各加一個支援活動：開始之前的 training，發布之後的 response。這個系列對應的方式是：
| Microsoft SDL | 這個系列 |
|---|---|
| training | 這 30 天本身 |
| requirements、design | 第 1 週：需求與設計 |
| implementation | 第 2、3 週：拆成「寫程式的 AI」與「AI 寫出的程式」 |
| verification | 第 4 週：驗證 |
| release、response | 第 5 週：發布、維運與回應 |
NIST SP 800-218（Secure Software Development Framework，簡稱 SSDF，1.1 版，2022 年 2 月）不照時間排，而是把實務分成四組：
| 組別 | 在做什麼 | 對應到這個系列 |
|---|---|---|
| PO（Prepare the Organization） | 讓人、流程、工具準備好做安全開發 | 第 1 週 PO.1（定義安全需求）；第 2 週 PO.3（toolchain）、PO.5（開發環境與開發電腦） |
| PS（Protect the Software） | 保護程式碼不被竄改或未授權存取 | 第 2 週 PS.1 |
| PW（Produce Well-Secured Software） | 產出漏洞少的軟體 | 第 1 週 PW.1（設計與 threat modeling）；第 3 週 PW.4（優先重用成熟元件）、PW.5（secure coding）；第 4 週 PW.7（code review）、PW.8（測試）；第 5 週 PW.9（預設安全設定） |
| RV（Respond to Vulnerabilities） | 找出並處理上線後的漏洞，追查根因 | 第 5 週 RV.1–RV.3 |
SSDF 的 1.2 版（SP 800-218 Rev. 1）在 2025 年 12 月發布初始公開草案，本文撰寫時尚未定稿，這個系列的實務編號以 1.1 版為準。
另外兩份常被一起提到：
這些標準寫給組織，動輒數十項實務。這個系列做的事，是把它們翻成一個人加一個 AI 做得到的版本：每個階段幾個檢查、幾段提示詞、幾個測試。
AI 會完成你說的需求，但你沒說的事，它不會替你想。它把一個功能的開發生命週期壓縮成一個下午；接下來 30 天，我們沿著 SSDLC，把被跳過的安全活動一個一個補回來。
iThome鐵人賽
看影片追技術