今天筆者要來處理一個很容易被忽略、但出事時會讓整間公司睡不著的問題： API key、Token、帳號密碼，居然直接寫在程式碼裡！ 😱 這次我用 GitHub Copilot 的 Agent mode，讓它先掃描、再修復，最後還要自己驗證結果，看看 AI 到底能不能幫我們把這個安全性魔王關打掉。

這篇對誰有用？如果你正在維護 C#、Python、Node.js 專案，或是平常會把設定檔一起丟進 GitHub 的朋友。 雖然現在的 Model 已經很少會犯「把 Secret 寫死在原始碼」這種錯，但是……不怕一萬，只怕萬一啊。

更何況，AI 產生程式碼的速度很快，快到你還沒喝完一口咖啡，API key 已經被它「熱心地」塞進設定檔了。 所以筆者這次實作底下檢驗流程：先掃描，再修復，最後驗證。

🔐 Secret 為什麼不能直接寫在程式裡？
安全性處理的基本原則：不要讓 Secret 跟著程式碼一起旅行。
Secret 可能包含 API key、Token、密碼、Connection String、JWT secret，甚至是第三方服務的登入資訊。 一旦這些值被 commit 到 Git repository，後面就算刪掉，Git history 可能還是留著，等於把家門鑰匙複製好幾把，然後放在門口說：「我刪掉了喔～」😅

🕵️ 先讓 Copilot 掃描整個 Codebase
範例專案故意留下不安全的寫法，方便測試掃描與修復流程。
使用微軟示範用的 C# 專案，裡面有付款、Email、資料庫存取等功能，故意在幾個檔案放入硬編碼的 key 與 token。 如下圖，AppConfig.cs 裡面直接出現一堆敏感值，看到這種畫面，資安同事大概已經開始深呼吸了

🔎 第一步：只做 Detect & Assess
我先用 Copilot Agent mode 針對整個 codebase 進行安全性檢查。
接著我叫出 GitHub Copilot 的 Agent mode，先不要急著改程式，我要求 Copilot 完成以下事情：

找出 API key、Token、密碼、帳號與其他敏感資料。
標示出檔案與行號，說明每一個風險。
不要在輸出結果或 log 中暴露 Secret 的完整內容。

掃描完成後，Copilot 會列出發現的位置，這時候可以直接按一下結果，跳到對應的程式碼。 這個流程很適合用來做 code review 的第一輪，至少不用靠肉眼在幾千行程式裡面找 token、password、secret 找到眼神死。

🧩 把掃描與重構流程做成可重複使用的 Slash Command
Security Scan 流程包含分析、修改、驗證與產出報告。
**
Identify：找出 API key、Token、密碼、Connection String 等敏感值。
Assess：說明每一個發現的風險與影響範圍。
Remediate：移除 hard-coded Secret，改由環境變數或 Secret Manager 取得。
Validate：確認程式仍可建置、執行，且不會把敏感值寫進輸出。
Report：產生改善報告，列出已修復與仍需人工處理的項目。
**

這是一個很標準、也很實務的安全性修復模式。重點不是叫 AI 「幫我修好」，而是要把驗證條件寫清楚。 否則 AI 很可能改完就跟你說成功，結果程式根本 build 不起來。

🛠️ Agent mode 實際修復：把 Secret 移到環境變數
接著我讓 Agent mode 根據掃描報告進行修改，要求它不要只把字串刪掉，而是要補上正確的讀取方式。 例如原本是這樣的硬編碼寫法：

private const string MailgunApiKey = "hard-coded-secret";

修復後則改成從設定或環境變數讀取，概念如下：

private readonly string _mailgunApiKey =>
configuration?["Mailgun:ApiKey"]??
Environment.GetEnvironmentVariable("MAILGUN_API_KEY")??
string.Empty;

這樣程式碼本身不再保存真正的 Secret，部署時再透過環境變數、CI/CD secret injection， 或 Azure Key Vault 提供實際值。開發環境可以用 user secrets，Production 則不要拿 .env 當萬靈丹，該用正式的 Secret Manager 就用，不要省這個錢，省到最後通常是用時間和頭髮付費。

修復完成後，多數 Secret 已改由系統環境變數提供。
Email service 也改成統一從環境變數取得敏感設定。

修復後，Copilot 也產生了一份報告，列出原本在哪些檔案發現哪些 key、做了什麼替換，以及哪些風險仍然需要人工處理。 這種報告很適合放在 Pull Request 裡面，讓 reviewer 不用猜「到底改了什麼」。

實作細節的部分，請參考完整版影片囉

🎯 今日結論
今天筆者用 GitHub Copilot Agent mode 實作了一個完整的 Secret scanning workflow： 從 codebase 掃描開始，找出 hardcode 的 API key、Token、密碼與加密金鑰， 接著改成環境變數或設定來源，產生本機設定腳本，補上 Git 防護，最後再透過 build 與執行測試確認結果。

這個流程不是什麼高深魔法，卻是非常容易被忽略的基本功。 尤其現在大家都用 AI 快速產生程式碼，更應該把 Security scan 放進日常開發、Pull Request 與 CI/CD 裡面。 畢竟 API key 一旦上 GitHub，通常不是「刪掉就好」，而是要趕快撤銷、重新產生，然後開始追查誰看過……那個夜班就來了