上周有個后端同事跟我吐槽：安全工具報了一堆"密碼硬編碼"警告，點進去發(fā)現(xiàn)全是注釋里的示例代碼。這種誤報煩人，但換個角度想——工具是怎么"看懂"代碼的？今天拆開Bandit，看看它怎么做到不執(zhí)行一行代碼，卻能精準定位真漏洞。

AST：讓代碼變成樹

Bandit的核心不是正則表達式，而是抽象語法樹（AST，Abstract Syntax Tree）。

AST是什么？簡單說，就是把你的Python代碼解析成一棵樹，每個節(jié)點代表代碼的結構元素——變量賦值、函數(shù)調用、循環(huán)、條件判斷，各自有明確的層級關系。

這和文本搜索的本質區(qū)別在哪？搜"password"字符串，注釋、變量名、文檔、真密碼全混在一起。但AST知道上下文：這個字符串是躺在注釋里無所事事，還是被賦值給了敏感變量，又或者直接傳進了eval()這種危險函數(shù)。

原文舉了個例子：eval()調用在AST里是一個明確的函數(shù)調用節(jié)點，帶有參數(shù)子節(jié)點。Bandit不需要猜測，它直接"看見"代碼的意圖結構。

插件分工：每種漏洞有專人盯

Bandit不搞大一統(tǒng)檢測，而是用插件化設計，每種漏洞類型有專門的檢查邏輯：

黑名單插件：盯死危險模塊。pickle、telnetlib這類庫一出現(xiàn)就報警。原文提到，這些模塊本身設計就有安全隱患，直接禁用是最安全的策略。

函數(shù)調用插件：監(jiān)控危險調用模式。比如subprocess.shell=True這種寫法，AST能識別出subprocess模塊調用、shell參數(shù)被設為True這個具體模式，而不是模糊匹配字符串。

硬編碼密鑰插件：用啟發(fā)式規(guī)則識別密碼/API密鑰。這里原文明確說了是"heuristics（啟發(fā)式）"，不是絕對判定。工具會看字符串長度、字符分布、變量命名模式，給出一個概率判斷。

這種分工的好處是規(guī)則可維護。新漏洞類型？寫個新插件塞進去，不影響現(xiàn)有邏輯。

雙維度評分：Severity × Confidence

Bandit有個被低估的設計：每個發(fā)現(xiàn)同時標兩個維度。

Severity（嚴重等級）：Low/Medium/High，回答"這事有多糟"。硬編碼生產環(huán)境密碼是High，調試日志里漏了敏感信息可能是Medium。

Confidence（置信度）：回答"我有多確定這不是誤報"。同樣是密碼字符串，賦值給PASSWORD變量是高置信度，躺在注釋里被誤抓是低置信度。

原文說這是"one of Bandit's best features"。實際開發(fā)中，你可以配置CI只阻斷High+High的組合，Medium+Low的先放日志里人工復核。這比非黑即白的掃描器實用得多。

CI/CD里的速度優(yōu)勢

原文提到一個關鍵場景：GitHub Actions集成。

為什么Bandit特別適合流水線？因為它不編譯、不執(zhí)行，純靜態(tài)分析。原文說"scan thousands of lines in seconds"——這個速度在預提交階段跑完全無壓力。

更重要的是"illegal AST patterns"這個概念。代碼還沒合并，危險結構就被攔下來。這比等滲透測試報告出來再返工，成本低兩個數(shù)量級。

原文作者提到"as shown in my previous post"，說明他之前寫過具體集成教程。這類工具的價值不在掃描本身，而在嵌入工作流后的自動化攔截。

不是Linter，是安全解析器

原文結尾給Bandit定了性：security-focused parser（安全導向的解析器）。

這個區(qū)分很重要。Linter管風格、管語法錯誤，Bandit管的是代碼結構里的安全意圖。它理解Python的語義，而不只是文本。

對于25-40歲的后端開發(fā)者，這件事的啟示是：靜態(tài)分析工具已經進化到可以理解代碼結構，而不是玩正則表達式猜謎。選型時看兩點——有沒有AST基礎，評分系統(tǒng)是不是足夠精細讓你能配置閾值。Bandit在這兩點上都是開源方案里的標桿。

最后留個判斷：Python生態(tài)里安全工具很多，但Bandit的AST路線代表了一個趨勢——代碼分析正在從"文本模式匹配"轉向"結構語義理解"。這個轉變會讓誤報率持續(xù)下降，也讓安全左移真正可行。如果你還在用基于正則的掃描方案，是時候評估遷移了。