城牆再高、駐守再嚴，只要鑰匙被偷走，巨人就能直接走進來。

前言

在網路工程師的日子裡，我常常要管理帳號與權限，知道「誰能進門」比「門有多厚」更重要。
轉到 DevSecOps 後，這件事換了形式：

程式碼裡的 API Key、密碼、憑證，如果被不小心 commit 上 GitHub，就等於直接把城門鑰匙掛在大門上。

這也是為什麼「Secrets 檢查」要成為我們的第三道防線：它能在程式碼推送到遠端之前，自動檢查有沒有洩漏敏感資訊，把鑰匙收回來。

1. 為什麼要檢查 Secrets？

最常見的人為失誤：不小心把 AWS Key、Database 密碼、Token commit 上去。

外洩後果嚴重：攻擊者可以直接用鑰匙開門，不需要再繞牆或找漏洞。

常被忽略：很多人覺得「我 repo 是 private 就沒事」——其實一旦分享錯誤權限或備份流出，風險一樣存在。

DevSecOps 的安全檢查，除了守住程式碼與依賴，還必須守住「秘密」。

2. gitleaks 入門

這裡示範用 gitleaks(github)：一個開源工具，能自動掃描 Git repo，偵測常見的 Secrets。

安裝之後輸入指令掃描整個repo

gitleaks detect --source .

範例輸入

INFO[0000] scanning 45 files...
WARN[0001] file: config.py, line: 12, rule: Generic API Key
  Secret: sk_test_51H8r***************

這告訴你：
檔案 config.py 第 12 行疑似放了 API Key
規則：Generic API Key
Secret 值已被偵測出

gitleaks 使用正則規則，所以可能誤判。可以在 .gitleaks.toml 排除特定路徑或模式，但務必要小心，避免真的秘密被忽略。

3. 與 CI/CD 整合

在 .github/workflows/ci.yml 加入：

- name: Secrets scan (gitleaks)
  uses: gitleaks/gitleaks-action@v2
  with:
    args: detect --source . --no-banner --redact

這樣，每次 Push 或 Pull Request 時，CI 都會自動掃描程式碼裡是否含有敏感資訊。

建議和依賴檢查一樣，分階段：
初期：先報告（不阻擋 PR），觀察 repo 現況。
成熟後：高風險 Secrets（像 AWS Key）直接 fail，避免進主分支。

4. 三道城牆防線

到這裡，我們已經建立了 DevSecOps 的三道基礎防線：

1. Bandit (SAST) → 找程式碼裡的危險用法
2. pip-audit (Dependency Scanning) → 找第三方套件的已知漏洞
3. gitleaks (Secrets Detection) → 防止鑰匙被 commit 上 repo

這三道防線合起來，才能確保：

• 牆沒裂縫
• 城內沒臥底
• 鑰匙沒掉出來

5. 總結

今天我們導入了 Secrets 檢查：
gitleaks 能掃描程式碼，找出 API key、密碼、憑證是否洩漏
與 CI/CD 整合後，每次提交都能自動檢查
搭配前兩天的檢查，完成程式碼安全的三角防線

從網路工程師的角度看，這就像不只檢查「牆和巡邏兵」，還要確保「城門的鑰匙不會掉在地上」。
因為牆再高、兵再多，一把鑰匙，就足以讓敵人大搖大擺走進來。