大家好，我是 Maneshwar。我正在開發 git-lrc，一個會在每次提交時執行的 AI 程式碼審查工具。請給我們點贊，幫助開發者發現這個專案。歡迎試用並分享您的回饋，幫助我們改進產品。
Go 的標準庫非常完善，生態系統也很成熟。但這些都無法保護你免受密鑰洩漏和依賴項漏洞的侵害。
安全工具填補了這一空白。好訊息是：該領域最好的工具都是開源的、免費的，而且只需 1-10 分鐘即可完成設定。
以下四個工具功能強大，遠超其體積——它們的作用、重要性以及如何立即將它們融入您的工作流程。
-
Gitleaks－永不眠的秘密掃描儀
⭐ 2.6萬顆星 · gitleaks.io
Gitleaks 會掃描你的 git 歷史記錄（是的，整個歷史記錄）和你的工作樹，尋找洩漏的秘密——API 金鑰、AWS 憑證、JWT、私鑰，以及所有洩漏的機密資訊。
它基本上已成為事實上的標準。
gitleaks detect --source . -v這就是全部命令。
執行它，幾秒鐘之內它就會準確地告訴你，你搞砸了哪個提交、哪個文件、哪一行。
-
Semgrep — 類似 Grep 的程序，但它實際上能理解程式碼
⭐ 15k 顆星 · semgrep.dev
普通的grep就像一把錘子，而Semgrep指令則像一把手術刀。
它的不同之處在於：Semgrep 是語意化的。
如果你寫一條規則來找出值2 ，它將符合x = 1; y = x + 1因為它知道y值為 2。
那不是正規表示式的魔法，而是真正的程式碼理解。
具體到 Go 語言，這意味著你可以編寫類似「標記任何接受使用者控制輸入的exec.Command呼叫」這樣的規則，它會在你的程式碼庫中找到它們，即使變數名稱不同。
將其作為 pre-commit hook 執行，以便在錯誤程式碼進入 CI 之前將其捕獲：
semgrep --config=auto .auto配置功能會提取針對偵測到的任何語言量身定制的社群規則。
-
OSV-Scanner — 谷歌的漏洞偵探工具
⭐ 10k 星 · osv.dev
你的依賴項是個隱憂。我的也是。大多數專案對此討論得不夠。
OSV-Scanner 是 Google 的解決方案，它連接到OSV 資料庫——一個統一的漏洞資訊來源，匯總了來自數十個來源的資料。
將其指向您的go.mod文件，它會準確地告訴您哪些依賴項存在已知的 CVE 以及每個 CVE 的嚴重程度。
osv-scanner --lockfile=go.mod真正有用的功能是：引導式修復。它不會只是簡單地告訴你“你有 47 個漏洞”，而是根據影響範圍、依賴深度、嚴重性和投資回報率對修復方案進行排序。
這就像醫生告訴你「你生病了」和給你制定治療方案之間的區別。
-
govulncheck — 擁有超強腦力能量的官方帳號
⭐ 470 個星標 · pkg.go.dev/golang.org/x/vuln
別被它不多的星級評價所迷惑。這是 Go 團隊官方推出的 Go 漏洞掃描器，它的功能確實比大多數同類產品更強大。
大多數掃描器會說：“你導入了一個存在漏洞的庫，現在就該恐慌了。”
govulncheck 說：“你導入了一個存在漏洞的庫，而且你還在程式碼路徑中實際呼叫了存在漏洞的函數。”
這種差異非常顯著。信噪比簡直天壤之別。再也不會因為從未執行過的程式碼路徑而被大量的誤報淹沒了。
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...更神奇的是：它對編譯後的二進位也有效。
人工智慧改變了遊戲規則
這是沒人願意公開承認的事實：人工智慧正在將你團隊的每月程式碼量推高到一年前的 2 倍到 10 倍。
程式碼越多，差異就越多，就越容易出現一些不易察覺的問題，直到 PR 或生產環境才會被發現。
靜態掃描儀是必要的，但它們並非為這種體積而設計的。
它們能捕捉到已知的模式——洩漏的機密資訊、已知的CVE漏洞、已知的反模式。但它們無法捕捉到人工智慧引入的新型故障模式：
-
這段程式碼“看起來能執行”，但卻無法處理提示中遺漏的極端情況。
-
相同的提示符在不同的執行中會產生不同的實作。
-
隱藏在長達 400 行、無人問津的 AI 生成的差異比較表中的細微回歸問題
-
邏輯錯誤只在示範結束後，當著客戶的面才顯現出來。
當你發佈人工智慧產生的程式碼時，你有責任知道你發布的是什麼。
此模型可以產生補丁。
你的團隊仍然要對故障、漏洞、回溯以及客戶信任負責。
60秒控制點
這就是我建立git-lrc 的目的——在每次提交時執行微型 AI 程式碼審查，在差異進入 git 歷史記錄之前進行審查。
-
Git 原生：在提交時檢查暫存的差異，此時上下文仍然清晰。
-
快速：一次微評大約需要 30 到 60 秒。
-
實用：在程式碼遷移到下游之前，提供摘要以及錯誤、安全性和效能警告。
先審查小差異勝過後審查大差異。每次都是如此。
以上四個工具就是你的基礎。 git-lrc 是位於最頂層的驗證循環——它區分了「我們憑感覺寫的程式碼就發布了」和「我們發布了，而且我們知道我們發布了什麼」。
責任無法推卸，但你可以將檢查工作的部分自動化。
https://github.com/HexmosTech/git-lrc
原文出處：https://dev.to/lovestaco/4-open-source-security-tools-every-dev-should-know-35om
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
