安全掃描：Gitleaks 只掃被 checkout 的那條分支 - #6
Merged
Merged
Conversation
checkout 用 fetch-depth: 0，那會把每一條遠端分支都抓下來；而 `gitleaks git .` 掃的是這個 clone 裡的所有 ref，不只被 checkout 的那一條。 結果是任何一條還沒合併的分支上的誤報，都會讓這個倉庫之後每一個 PR 變紅， 而紅燈的位置與內容跟那個 PR 的 diff 毫無關係。 實際發生過：hoshi-svc 有一個只改了 .hoshi-build.yaml 的 PR 拿到 leaks found: 2，兩個 finding 都在另一條沒合併的分支的測試常數上 （const secret = "internal-secret-0123..."）。main 當時是綠的， 只是因為它最後一次掃描早於那條分支被推上來。 --log-opts=HEAD 把範圍收到被 checkout 的那條分支的完整歷史。 fetch-depth: 0 保留——「一個被刪掉的憑證仍然在歷史裡」那句照舊成立。 這不是把檢查放寬，實測（gitleaks 8.30.1）： - 那個 PR 的分支：30 commits／2 leaks／exit 1 → 24 commits／0 leaks／exit 0 - 誤報所在的分支自己：26 commits／2 leaks／exit 1（加了旗標仍然紅） 也就是說帶著問題的那條分支開 PR 時照樣擋得下來，只是不再殃及別人。 todo/gitleaks-掃描範圍.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
問題
security.yml的 checkout 用fetch-depth: 0，那會把每一條遠端分支都抓下來；而gitleaks git .掃的是這個 clone 裡的所有 ref，不只被 checkout 的那一條。結果：任何一條還沒合併的分支上的誤報，會讓這個倉庫之後每一個 PR 變紅，而紅燈的位置與內容跟那個 PR 的 diff 毫無關係。
這不是假設——已經發生過一次：一個只改了一行設定的 PR 拿到
leaks found: 2，而兩個 finding 都落在另一條還沒合併的分支的測試常數上。那個倉庫的main當時是綠的，不是因為它比較乾淨，只是因為它最後一次掃描的時間早於那條分支被推上來。一個位置與內容都與自己無關的紅燈，看的人只會學會忽略它——而那正是安全掃描最不該落到的狀態。
改法
--log-opts=HEAD，把範圍收到被 checkout 的那條分支的完整歷史。fetch-depth: 0保留：原本那句「一個被刪掉的憑證仍然在歷史裡，而它仍然是一個憑證」照舊成立——--log-opts=HEAD掃的仍然是完整歷史，去掉的只有「這個 clone 裡剛好還有哪些別的分支」這個與被測對象無關的變數。這不是把檢查放寬
用同一版 gitleaks（8.30.1，校驗碼比對過）實測兩種情況：
--log-opts=HEAD第二列是重點：帶著問題的那條分支自己被 checkout 時照樣紅、結束碼照樣是 1，也就是它開 PR 時仍然會被擋下來——只是不再殃及別人的 PR。
為什麼不只加允許清單
加允許清單只解決那一次。真正的問題是掃描結果取決於倉庫裡剛好有哪些分支：同一顆 commit 今天綠明天紅，而變數不在這個 PR 的 diff 裡。
Generated by Claude Code