接手既有系統的全碼健檢流程：從候選問題到可交付的報告

換開發團隊時，最大的未知不是報價，也不是簡報，而是程式碼現況。前任團隊留下什麼、哪裡可以放心、哪裡一碰就會出事，通常沒有人能在交接當天講清楚。如何挑選新的團隊，可參考挑選軟體開發廠商的判斷方式；本文處理選定之後最具體的一步：把程式碼現況，變成可以據以做決定的資訊。

軟體不會停在上線的那一天。Parnas，1994 提出軟體老化的概念：老化無法避免，但成因可以理解、影響可以限制、部分可以逆轉，因此長期的產品健康，應該比首次發行更受重視。Lehman，1980 的持續變更定律指向同一個方向：被使用、要反映現實的程式，若不持續調整，會逐漸變得不實用；而變更時若沒有投入維護工作，結構會劣化，複雜度會增加。運行一段時間的系統，正處在這個狀態：有人使用，改過很多次，而改動的理由多半沒有留在程式碼裡。

換團隊也是一種供應商風險。NIST SP 800-161 針對供應商與採購的系統、產品與服務可能帶來的風險，如惡意功能、仿冒與開發品質不良，提供識別、評估與降低風險的做法（Boyens 等，2024）。前任團隊留下的系統品質是否可靠，屬於需要識別與評估的那一類。全碼健檢是評估這一項的做法之一：不憑印象，直接讀程式碼。

全碼健檢的流程：掃描、候選、反證、報告

全碼健檢的對象是整套程式碼，不是挑幾個頁面抽查。流程分四段。第一段，把系統切成七個面向平行掃描，各自產生候選問題。第二段，逐條回到程式碼驗證，確認問題確實存在。第三段，做對抗式覆核，刻意找理由推翻自己的發現；覆核時要弄清楚兩件事：這段程式為什麼會在那裡，以及拆掉之後會發生什麼事。第四段，才把留下來的整理成報告。

面向怎麼切沒有唯一答案。OWASP ASVS，2025 是供開發者在建置、撰寫程式與測試網頁應用及服務時對照的驗證需求清單，可以用來確認常見的驗證項目沒有被漏掉。OWASP Top 10，2025 是專家共識整理出的網頁應用程式最嚴重安全風險清單，2025 年版為目前最新版，分級時可以對照，確認最嚴重的那一類風險沒有被漏掉。

這與弱點掃描、滲透測試回答的是不同的問題。兩者的差別與各自適用的時機，可看弱點掃描與滲透測試的差別。全碼健檢讀的是程式碼本身，因此看得到系統執行時不容易碰到的東西：從沒被觸發過的備援機制、被吞掉的錯誤，以及設定漏填時程式的行為。

以一次完整的健檢為例，合併後的候選問題約七十條，經過反證，近一成被駁回，其餘進入報告。被駁回的不是白做：每一條都留下判斷的理由，說明為什麼看起來像缺陷、實際上不是，後人才不會把同一個補丁當成錯誤拆掉。

反證是報告可信度的來源

接手方對健檢報告常有兩種擔心：灌水，以及誤報。灌水是把所有看起來可疑的地方都列進去，真正重要的幾條被埋在裡面。反證這一步，就是為了濾掉這一類。被駁回的候選，多半看起來像缺陷，其實是前人刻意留下的補丁。放回上下文來看，那段程式是為了處理某個問題而加的，把補丁拆掉，問題就會回來。出於好意的修正，反而製造事故。

誤報不只是浪費時間，還會傷害信任。Sadowski 等，2018 整理在 Google 建置靜態分析工具的經驗，指出誤報會讓使用者不信任分析結果；程式碼審查中的檢查，準則是有效誤報低於 10%，編譯期檢查則不得產生有效誤報。訪談開發者的研究也發現，誤報與警告的呈現方式，是開發者不使用靜態分析工具的主因之一，即使受訪者普遍認為工具有幫助（Johnson 等，2013）。這兩項研究談的是自動化工具，不是人工健檢，數字不能直接對照；但原理相通：報告裡每多一條站不住腳的發現，讀者對其餘發現的信任就少一分。

報告寫的是客人會遇到什麼事

報告的寫法，決定報告能不能被使用。技術術語的清單，只有寫程式的人讀得懂；負責產品的人需要知道的，是使用者或客戶會遇到什麼事。一份可用的報告，把發現分成紅燈、黃燈、綠燈。紅燈是會傷到人、掉資料、被攻擊的問題，每一條用四欄寫：使用者或客戶會遇到的事、什麼時候發生、誰該修、估時。紅燈的條目讀起來像這樣：

• 後台登入沒有次數限制，失敗的嘗試也不記錄：帳號可能被反覆嘗試，事後查不到任何痕跡。
• 權限已被撤銷的人，仍然能在一段時間內改動資料：停用帳號之後，系統沒有同步擋下。
• 部署指令會永久刪除尚未進入版本控制的檔案：下一次部署，這些檔案就會消失，而且找不回來。

黃燈列出還不到紅燈的問題。綠燈單獨列出做得好、不可被後人拆掉的部分，因為接手後的事故，有一類正是新團隊把前人刻意的設計當成缺陷拆掉。另有一節〈現在不該做的事〉，把當下不值得翻修的項目寫明，避免健檢結束後變成一輪大改。這個寫法與監控的原則同向：SRE 文獻中談監控分散式系統的章節主張，告警原則上只針對需要人工介入、影響使用者的問題，並以症狀為主、原因為輔（Ewaschuk，2017）。報告同樣先寫症狀，再寫原因在哪裡。

最貴的缺陷是不報錯的

最貴的缺陷往往不報錯。功能看起來正常，自動化測試全綠，沒有任何錯誤訊息，防護卻從來沒有生效。這類缺陷在驗收時看不出來，要等出事才會被發現。這一類缺陷的形態大致相同，以下是幾個已去識別的例子：

• 機器人驗證的金鑰沒設，程式一碰到沒設就整個關閉並放行，連一行紀錄都沒有；健檢時送出假的驗證碼，照樣走到下一步。
• 備援機制的判斷條件恆為真，備援從來沒有被觸發過。
• 空的錯誤處理搭配後端的整筆覆寫：寫入失敗被吞掉，資料被靜默毀損，畫面還回報成功。
• 某些框架版本不會接住非同步函式丟出的錯誤，只加一層錯誤處理沒有用。
• 環境變數沒設，系統被當成測試環境，信件全部被擋下，也沒有任何告警。
• 日誌輪替連續失敗，沒有人知道。

對策有三項。第一，缺設定時拒絕啟動，或至少明確告警：失敗要有聲音，並且留下一行紀錄。第二，每個修正留下一個壞了就會失敗的檢查，不是只留一段註解；做法是負向測試，也就是故意餵入錯誤的輸入，證明這個檢查真的抓得到問題。第三，區分「檢查了」和「檢查對了」：測試跑在假資料上，但搬家或改設定之後，假資料的開關可能悄悄失效，測試照樣綠燈，其實打到了真的系統。所以這支測試連到哪裡，也要列入檢查；測試環境的延遲則要先量測，再依比例調整等待時間，避免固定等待造成誤報。

後台要不要留，用上線後的操作紀錄回答

被建議一定要做後台、或一定要保留後台時，上線後的操作紀錄是最直接的證據。做法是看三個月的操作紀錄：先排除登入、登出與帳號管理，只算真正的內容編輯。如果內容編輯趨近零，就把內容放進版本控制，後台只留檢視。這樣每次改動都留下版本紀錄與理由，也不用再為沒有出現的使用者維護一整套編輯介面。用腳本直接改資料庫的變更，在稽核紀錄上是隱形的；內容進了版本控制，每次變更都看得到。下線後台無法回頭，所以較穩的做法，是先改成唯讀並觀察一段時間，再決定要不要下線。

第一個月：舊問題不翻修，新程式不帶新風險

接手的第一個月，範圍要先劃清楚：舊系統既有的問題，先不趁機翻修；新增的程式，不得帶來新的風險。接手初期掌握的資訊最少，大幅翻修的風險最高；新程式則是開發團隊完全能控制的部分。NIST 的 SSDF 將安全開發實務描述為一組高階做法，可加入任何軟體開發生命週期模型，目標包括降低釋出軟體中的漏洞、限制未處理缺陷的影響，並處理根本原因（Souppaya 等，2022）。舊問題先記錄、排序，新程式則守住一組具體規則：

• 資料庫查詢一律參數化。
• 讀寫資料時檢查擁有者，查詢條件同時限定資料與使用者。
• 金流等第三方服務的回呼，一律驗證簽章。
• 機密不進版本控制，記錄裡也不印原文，只比對雜湊或印出長度。

有 AI 協助開發時，權限再往下切一層：AI 只做功能；資安設定、版本控制追蹤與部署腳本的變更，一律由負責人先確認，AI 發現資安問題只回報、不自行修改。理由很實際：部署若依賴拉取最新版本，一個錯誤的追蹤變更就可能讓檔案被刪，代價是停機。

第一個月結束後，系統進入長期維運。磨人開發團隊的 Polish+ 接手與長期維運服務 承接這一段；長期維運的做法，可看配合教育部專案的長期維運案例。

測試環境要把真實世界隔在外面

接手後的每一次測試，都要確保不會碰到真實使用者。測試環境的信件只寄給操作者本人，或乾脆不寄；內部介面沒有設定金鑰、或金鑰長度不足時，對外一律回應找不到，看起來就是不存在。回應的內容不帶個資，信箱只在伺服器端、寄信的那一刻查詢，不經過任何公開介面。

資料表依性質分成可修改、只讀、只新增三級：可修改的資料表，改動前先存下可還原的內容；會員個資所在的資料表只讀；其餘既有資料表只新建，不取代。正式資料庫只用唯讀工具，資料庫變更腳本必須能重複執行。

改動可能弄掛整站的設定，程序固定：整包備份、在隔離環境測試、套用失敗時自動還原，最後在公網逐項驗證。檔案同步腳本則內建防呆：來源目錄是空的時中止，避免建置不完整時把遠端清空；要刪除的遠端檔案超過一半時中止，除非明確加上旗標；每個檔案上傳後，比對雜湊是否一致。

全碼健檢不適合的情況

以下情況，不建議做全碼健檢。

• 系統快要汰換：健檢的價值要靠後續修復才能實現，系統即將淘汰時，這筆投入不值得。
• 拿不到原始碼：全碼健檢讀的就是程式碼，沒有原始碼就無從進行。
• 只想找一個價格低的維護窗口：全碼健檢是為了看清現況，再決定怎麼修。

接手前要準備什麼

開始前需要備妥三項資料：原始碼或其存取權、目前的部署方式，以及最近半年出過的問題。三項齊備，就能判斷健檢的範圍與次序。備妥後，可以說明目前的系統狀況，與開發團隊約時間討論。