2026/9/15 · AI 上線專家

接手程式碼時最常踩的第一個坑：密碼寫死在檔案裡、金鑰推上 GitHub

接手程式碼時最常踩的第一個坑：密碼寫死在檔案裡、金鑰推上 GitHub

接手時才發現：金鑰不在保險箱、在程式碼裡

工程師交接完了,系統能跑,合約也簽了。您打開專案資料夾準備了解架構,第一眼就看到 config.js 裡寫著:

const DB_PASSWORD = "prod_db_2024!@#";
const STRIPE_SECRET_KEY = "sk_live_abc123xyz...";

這是接手程式碼時最常見、也最危險的第一個坑:<cite index="1-3">GitGuardian 2026 年報告顯示,光是 2025 年就有 2,865 萬組新的寫死憑證出現在公開 GitHub 提交中</cite>,而您手上這套系統,可能也是其中之一。

更麻煩的是,您不確定這些金鑰還有誰看得到、有沒有被推上 GitHub、以及現在換掉會不會讓系統停擺。這不是「改天再處理」的技術債——<cite index="3-4">被盜憑證仍然是資料外洩最常見的根本原因</cite>。

為什麼工程師會把密碼寫死在程式裡？

這不是粗心,是開發流程的結構性問題。

一開始測試時,工程師會先把 API 金鑰直接寫在程式碼裡「讓功能先跑起來」。測試通過後,原本應該把這些金鑰搬到環境變數或金鑰管理工具,但趕著交件、或根本不知道怎麼做,金鑰就這樣留在程式碼裡上線了。

<cite index="10-3">GitGuardian 2026 年報告發現,AI 輔助的程式碼提交洩漏憑證的比例是 3.2%,約為基準值的兩倍</cite>。當工程師用 Cursor、ChatGPT 或 Claude 快速產出程式碼時,AI 產生的範例往往直接包含寫死的金鑰格式,開發者複製貼上後沒有改掉就推上版本庫了。

實務上常見的寫死位置包括:

  • 設定檔:config.js、settings.py、application.yml
  • 環境變數範例檔:.env.example 裡寫的是真實金鑰,不是範例
  • 測試程式碼:test/api.spec.js 裡為了方便測試寫死的 token
  • 註解或文件:README.md 或程式碼註解裡留下的「測試用金鑰」
  • Docker 映像檔:Dockerfile 或 docker-compose.yml 裡的 ENV 變數

接手後該怎麼檢查、怎麼換掉？

第一步:找出所有寫死的金鑰

手動翻程式碼找不完,您需要工具協助。<cite index="15-3">將憑證存放在環境變數中透過 .env 檔案有助於防止在原始碼和版本控制中意外暴露</cite>,但首先您得知道有哪些憑證需要搬出來。

實務上可以用:

  • GitHub 內建的 Secret Scanning:如果程式碼放在 GitHub,它會自動掃描已知格式的 API 金鑰
  • 開源工具:gitleaks、trufflehog、detect-secrets 可以掃描本地專案和 git 歷史
  • 手動關鍵字搜尋:在專案裡全域搜尋 password、secret、api_key、token、SK_、AKIA (AWS 金鑰開頭)等字串

掃描完後,列出清單:哪些服務、哪些金鑰、在哪些檔案裡、最後一次修改時間。這份清單就是接下來的作戰地圖。

第二步:確認金鑰的影響範圍

換掉金鑰之前,您得先知道:

  • 這個金鑰控制什麼? 是資料庫連線、金流 API、簡訊服務,還是第三方登入?
  • 有沒有其他地方也在用? 同一組金鑰可能同時寫在正式環境和測試環境的設定檔裡
  • 換掉後系統會不會斷? 如果是資料庫密碼,換掉前得先在資料庫系統裡建立新帳號或改密碼

<cite index="4-7">GitGuardian 發現,近 70% 在 2022 年被識別為合法的憑證在 2025 年 1 月仍然有效,64% 在 2026 年 1 月仍未被撤銷</cite>。這表示大多數團隊即使知道金鑰外洩,也沒有實際換掉——因為換金鑰比想像中麻煩得多。

第三步:安全地換掉金鑰

正確的換金鑰流程是:

  1. 建立新金鑰:到服務提供商後台 (Stripe、SendGrid、Google Cloud 等) 產生新的 API 金鑰
  2. 改用環境變數:把新金鑰寫進 .env 檔案或金鑰管理工具 (如 AWS Secrets Manager、Doppler、1Password),不要再寫在程式碼裡
  3. 更新部署流程:確保正式環境讀取的是環境變數,不是程式碼裡寫死的值
  4. 測試新金鑰:在測試環境先確認新金鑰能正常運作
  5. 部署更新:把使用新金鑰的版本部署上線
  6. 撤銷舊金鑰:確認系統穩定運作後,才到服務後台撤銷舊金鑰

<cite index="15-1,15-2">每個環境使用唯一的憑證,絕不跨階段共用憑證。利用 CI/CD 管道在部署時注入特定環境的憑證,並為正式環境工作負載使用憑證管理工具</cite>。

為什麼不能直接撤銷舊金鑰? 因為您不確定系統是不是真的已經完全改用新金鑰。如果正式環境某個角落還在讀取寫死的舊金鑰,您一撤銷,那個功能就斷了。

第四步:清理 git 歷史紀錄 (如果已經推上 GitHub)

即使您改掉了程式碼裡的金鑰,git 歷史紀錄還是會留著。任何人 clone 您的 repo,都能用 git log 翻出舊的 commit 裡寫死的金鑰。

清理 git 歷史需要用 git filter-branch 或 BFG Repo-Cleaner,但這會改寫整個 repo 的 commit 歷史,協作中的團隊成員都得重新 clone。實務上更穩妥的做法是:直接撤銷舊金鑰、換新的,而不是試圖「讓外洩沒發生過」。

接手時該跟前任工程師要什麼?

如果前任工程師還聯絡得上,接手時別只問「程式碼在哪」,該問:

  • 所有第三方服務的帳號權限:Stripe、SendGrid、Google Cloud、AWS 等服務的後台登入權,您才能自己產生新金鑰
  • 金鑰清單與用途:哪些 API 金鑰控制什麼功能、哪些還在用、哪些可以直接撤銷
  • 環境變數設定:正式環境的 .env 檔案或部署平台 (Vercel、Render、Heroku) 上設定的環境變數實際值
  • 資料庫與伺服器的 root 權限:您才有權限改資料庫密碼或建立新使用者

如果前任工程師已經失聯,您可能得逐一聯絡服務提供商客服,證明您是系統擁有者後重設權限。這個流程可能要兩週到一個月,而在這段期間系統仍然暴露在風險中。

下一步:建立金鑰管理的長期機制

把寫死的金鑰清乾淨只是治標。長期來看,您需要:

  • 強制使用環境變數:開發團隊的 code review 流程裡加上「不准寫死金鑰」的檢查點
  • 自動化掃描:在 CI/CD 流程加上 gitleaks 或 GitHub Secret Scanning,每次 push 都自動檢查
  • 定期輪換金鑰:<cite index="16-19,16-20,16-21,16-22">資料庫憑證與加密金鑰建議每月或每季輪換,API 金鑰每季輪換,較不關鍵的服務憑證每年輪換。在團隊成員離職、資安事件或潛在暴露後立即輪換</cite>
  • 使用金鑰管理工具:如果系統規模成長,考慮導入 AWS Secrets Manager、HashiCorp Vault 或 Doppler

如果您現在手上正接著一套「能跑、但不知道金鑰安不安全」的系統,這篇文章列出的檢查步驟可以幫您找出風險點。想了解接手專案時完整的技術交接清單與資安檢查項目,或需要協助評估手上系統的金鑰風險,歡迎透過免費程式碼健診讓我們幫您看一次。

AI 上線專家 專門協助台灣中小企業安全接手、檢查與上線外包或 AI 產出的程式碼。我們知道「能跑」跟「能安心上線」是兩回事,也知道換金鑰不只是改幾行程式碼而已。