Go Crypto API Misuse 論文閱讀分析：很多基礎設施真正危險的，不是沒用加密，而是用了還以為自己已經安全

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：Evaluating Cryptographic API Misuse Detectors for Go
• 作者：Vivi Andersson、Martin Monperrus
• 年份：2026
• 來源：arXiv:2604.24085
• 論文連結：https://arxiv.org/abs/2604.24085
• DOI：10.48550/arXiv.2604.24085
• 主題：Go Security、Cryptographic API Misuse、Static Analysis、AppSec、TLS Security、Software Supply Chain

這篇 paper 很實務，而且我覺得它戳到一個很多團隊其實不太想承認的痛點：

很多系統不是「沒用加密」才危險，而是明明用了 crypto library，團隊也自認有做安全，結果真正出事的點其實卡在 API 用法、參數、驗證語意和工具誤判上。

尤其在 Go 世界，這件事更值得寫。因為現在大量 security-critical infrastructure 都是 Go：

• 憑證服務
• service mesh
• Kubernetes 生態
• IaC 與雲端基礎設施工具

你很難把它當成冷門語言邊角料。作者一開始就把問題講很白：Go 不是沒有 crypto API，而是正因為它太常被拿去做高敏感基礎設施，crypto API misuse 更不該繼續是低可見度問題。

如果要先講這篇最重要的一句，我會這樣下：

很多基礎設施真正危險的，不是沒上加密，而是你以為「有呼叫到加密函式」就等於安全，但真正的破口常常藏在錯的 defaults、錯的 callback、錯的 key/IV、錯的驗證流程，以及彼此根本沒講好什麼叫誤用的工具鏈裡。

這篇在處理什麼問題？

論文研究的是 Go 生態中的 cryptographic API misuse detection。換句話說，不是在問某個密碼學演算法數學上安不安全，而是在問：

• 開發者有沒有把加密 API 用對？
• 現有工具抓不抓得到？
• 不同工具抓到的東西到底有多一致？

這個問題的重要性在於，真實世界的加密事故很多都不是因為 AES 突然失效，而是因為：

• 拿 math/rand 當安全亂數
• 把 TLS 驗證關掉
• 用固定 key / predictable IV
• SSH host key 不驗
• JWT 根本沒做驗證

也就是說，問題常常不在 primitive 本身，而在 API-level security invariants 根本沒被守住。

作者做了什麼？

這篇做了兩件很重要的事。

第一，他們盤點了目前 Go 可用的 4 個代表性工具：

• CodeQL
• Gopher
• Gosec
• Snyk Code

第二，他們自己整理出一套統一 taxonomy，把各工具原本分散、粒度不一的規則收斂成 14 類 cryptographic misuse，然後拿這套 taxonomy 去跑 328 個 security-relevant 的 Go 開源專案。

這 328 個專案不是隨便抓的。作者先從 920 個熱門 Go repo 篩起，再挑掉：

• 不健康、沒在維護的
• crypto 不是核心用途的
• 只是教學或不具代表性的

最後留下的專案，都是比較接近真實基礎設施現場的東西。中位數規模約 58,761 LOC，中位數有 9,096 stars、167 contributors。這不算玩具場。

14 類 misuse：這篇其實在幫大家把「Go 密碼學踩雷圖」畫出來

我很喜歡這篇的一點，是它沒有只停在「某工具抓了很多警告」這種表面比較，而是先把問題空間整理出來。

作者整理出的 14 類誤用，大致分成 6 個領域：

• Cryptographic primitives：不安全演算法、非密碼學 PRNG、deprecated function
• Key management：固定 / 可預測 key、短 key、固定或可預測 IV
• Password-based KDF：salt 太短、salt 可預測、iteration 太低
• Transport security：HTTP 明文、TLS/SSL 問題
• SSH：不安全 cipher suite、沒驗 host key
• Token auth：JWT 沒驗證

這些類型裡，很多都對應到真實 CVE。換句話說，這不是學術界自己 invent 出來的 checklist，而是把 production 裡反覆出現過的踩雷模式收斂成一張表。

我覺得這種 taxonomy 的價值很高，因為它提醒大家：

crypto misuse 不是單一 bug family，而是一整套「你以為自己在用安全元件，實際上卻把安全保證接錯線」的工程問題。

結果有多大條？328 個專案裡抓到 7,473 個 misuse

先看最直觀的數字：作者在 328 個 Go 專案裡，一共抓到 7,473 個 cryptographic API misuses。

這個量不只是「有些問題」，而是說明：

在 Go 基礎設施世界裡，crypto 誤用不是少數邊角案例，而是相當普遍的工程衛生問題。

更有意思的是各工具差異非常大：

• CodeQL：256 個
• Gopher：1,266 個
• Gosec：4,196 個
• Snyk Code：1,755 個

同一個生態、同一批專案、同一類問題，最後差到這種量級，其實已經不是單純「各有側重」而已，而是：

不同工具對「什麼算誤用」的世界觀本來就差很多。

最值得注意的，不是哪家抓最多，而是大家根本沒共識

這篇最好看的地方在這裡。

它不是只比 coverage，還去看 tool consensus。結果非常有戲：

• 四個工具合起來共有 6,152 個 unique detections
• 其中只有 1.3% 是四個工具都同意的
• CodeQL 有 81.7% 的 alert 會和別人重疊
• Gosec 的大量告警則高度是自己獨有

這幾個數字一起看，意思其實很殘酷：

現在的 Go crypto misuse detection，不是「大家都差不多，只是各有強弱」，而是整個領域對 ground truth 還很破碎。

也因此，當某個工具跳出一堆紅字時，你不一定該先問「它抓到了什麼」，而要先問：

• 它是不是在過度保守？
• 它有沒有理解這段程式碼的上下文？
• 它抓的是 security-relevant usage 還是只是 pattern match？

幾個具代表性的觀察

1. Gopher coverage 最廣，但也最容易看起來很吵

Gopher 支援 14 類裡的 13 類，是 coverage 最廣的；但它也常因為 heuristic 太寬，帶出大量可能不具安全意義的告警。

例如某些 rule 它會把使用 chacha20.NewUnauthenticatedCipher 的地方全部標起來，即便後續其實有做完整認證；HTTP 或 deprecated 類規則也出現偏多的警告，作者認為這反映出它有時過度積極。

這種工具的價值不是零，而是它比較像：

高召回率的探索型掃描器。

你可以拿它盡量挖，但不能把它的輸出直接當 final truth。

2. Gosec 最像 CI 裡大家會順手接的工具，但誤報風險也最實際

Gosec 的優點很明確：

• 全專案都能跑
• 中位數只要 29 秒
• 支援 rule selection
• 還有 severity 與 confidence

從工程導入角度，它很像是最容易被放進 pipeline 的那種工具。

但問題也很清楚。像 TLS/SSL rule 的抽樣裡，作者發現 Gosec 常把一些其實有正確設定、或只是可選配置存在的情境也打成問題；在 SSH host key validation 也會把測試檔或語境 benign 的情況一起抓進來。

也就是說：

Gosec 很適合當大規模衛生掃描器，但如果沒有後續 triage，很容易把工程團隊拖進告警疲勞。

3. Snyk Code coverage 不大，但 context-aware precision 反而不錯

Snyk Code 只覆蓋 4 類，看起來不廣；但作者手動抽樣時，發現它在 TLS/SSL 問題上誤報明顯比較少，對安全語境的理解也比 Gosec 好。

這點很有意思，因為它反映出一個實務取捨：

• 有些工具想抓得廣，結果上下文理解不夠
• 有些工具抓得少，但每個警告比較值得人看

所以團隊真正要決定的，不只是「誰比較強」，而是：

你現在缺的是 coverage，還是缺一個比較不浪費工程師時間的 precision profile。

4. CodeQL 抓得最少，但在高階 data-flow / callback 問題上有獨門價值

CodeQL 總數最少，只有 256 個；而且最慢，中位數要 219 秒。看數字很像會先被嫌。

但這篇指出一個很重要的點：在 SSH host key validation 類型上，CodeQL 不只抓 InsecureIgnoreHostKey 這種顯眼 pattern，還能抓到更複雜的 callback data flow，例如 callback 直接回 nil 造成實質停用驗證。

這類問題剛好就是 pattern-based tool 容易漏掉的地方。

所以 CodeQL 的角色比較像：

慢、但在某些高價值語意型規則上比較像真的在理解程式。

這篇其實不是在比掃描器，而是在揭露「安全語意沒有被標準化」

很多人看這篇可能會先關心哪個工具第一名，但我覺得更值得帶走的是另一層結論：

現在 crypto misuse detection 最大的問題，不只是 detector 強不強，而是 API-level security invariants 其實還沒有被形式化到足夠一致。

例如同樣是 TLS 問題：

• 有人把出現某個設定點就算風險
• 有人會看實際配置值
• 有人會看 callback flow
• 有人只做表層 pattern

這就導致工具之間的輸出，很難當成可直接比較的 benchmark 結果。

換句話說，這篇不是只在告訴你「哪個 scanner 好用」，而是在說：

如果安全界連「什麼叫在 Go 裡安全地使用 crypto API」都還沒能在工具層穩定落地，那後續任何 coverage、precision、LLM vs static analysis 的比較，都有一部分是建立在鬆動地基上。

速度也很現實：CI 不是無限耐心

作者也有量工具執行時間，這點很接地氣：

• CodeQL：219 秒中位數（其中 144 秒是建 DB）
• Gopher：63 秒
• Gosec：29 秒
• Snyk Code：16 秒

這代表什麼？代表即便某工具理論上更細、更深，導入進 CI / PR gate 時也會碰到工程現實：

• 你能不能承受 latency？
• 要不要每次都全跑？
• 哪些規則適合 pre-merge，哪些比較適合 nightly？

所以真正成熟的做法恐怕不是單押一把，而是分層：

• 快的工具守日常 hygiene
• 深的工具守高風險路徑
• 重疊警報優先人工看

對實務團隊的啟示

如果你在維護 Go 基礎設施、平台元件、雲原生控制面或任何碰到 TLS / SSH / token / key material 的東西，這篇有幾個很直接的啟示。

• 第一，不要把「有跑 scanner」誤認成「crypto hygiene 已經有被守住」。
• 第二，不同工具其實在回答不同問題，不能用單一工具輸出當 ground truth。
• 第三，cross-tool overlap 值得特別重視，因為作者觀察到多工具同意時，真陽性機率通常更高。
• 第四，很多風險不是語法錯，而是語意錯；像 callback、config value、驗證邏輯這種地方，值得額外 code review。
• 第五，團隊應該把一些 crypto invariants 明文化，例如：禁止 math/rand 進安全路徑、禁止跳過 host key verification、TLS 最低版本與 verification policy 要有硬規範。

我自己會把這篇翻成一句比較不客氣的話：

很多基礎設施團隊現在缺的，不是再多一個掃描器，而是先承認「加密正確性」不是函式庫 import 了就自動成立，它需要被當成一組可驗、可審、可在 pipeline 裡執法的工程不變量。

結語

Evaluating Cryptographic API Misuse Detectors for Go 值得看的地方，不只是它跑了 328 個專案、抓出 7,473 個問題，而是它把一個常被誤會的事講清楚：

很多 crypto 風險真正麻煩的，不是大家完全沒做安全，而是每個人都以為自己已經做了，直到你發現工具彼此根本不同意、設定語意根本沒被守住，而 production 還在拿這些程式承載真正的信任。

如果要用一句話收尾，我會這樣寫：

很多 Go 基礎設施真正危險的，不是沒用加密，而是把「有用到 crypto API」誤當成「安全性已經落地」，但真正該被治理的其實是那些 key、IV、TLS、SSH、JWT 與 callback 背後的使用不變量。