程式碼安全稽核

把 duduclaw secaudit 指向一個 repository，它會像一個仔細的審查者一樣揪出安全問題：先跑快速掃描器，再讓一個 agent 讀有風險的模組，最後讓第二個 agent 在結果送到你面前之前試著推翻每一個發現項目。

這是什麼

靜態掃描器又快又準，但抓不到需要跨檔案推理的問題：一個受污染的值流過三個模組才被用到、一個狀態機可能被逼進壞的狀態、一條商業邏輯只在特定順序下才會出錯。語言模型能跟著這些路徑走，卻也會編出聽起來合理、其實不存在的 bug。duduclaw secaudit 兩種都跑，還讓它們互相檢查。

它重用平台原本就有的機制：multi-runtime agent 層負責深度閱讀，容器沙盒在沒有網路的環境跑概念驗證程式碼，別處用的同一套 maker-checker 紀律，在這裡變成一次對抗式覆核。它唯一沒有自己蓋的是靜態引擎：直接指揮你已經在信任的掃描器（gitleaks、semgrep、cargo-audit、osv-scanner），沒有重新發明一遍。

稽核流程

1. 情蒐與威脅建模（確定性、不用 LLM）。替 repo 建立輪廓（語言組成、進入點），並從 git 歷史挖掘經常出現安全相關 commit 的模組，讓後面比較貴的步驟先聚焦在風險高的地方。
2. 靜態掃描。 跑機器上已安裝的掃描器，把輸出統一成同一種發現項目格式。沒裝的掃描器會被回報成缺少並附上原因，不會被悄悄跳過。
3. AI 深度稽核（--profile deep）。在固定的 prompt 預算內逐一讀取排序後的模組，提出靜態工具抓不到的具體漏洞。--max-modules 設上限，不會失控跑下去。
4. 對抗式覆核。 每個 AI 候選項目交給一個全新的 agent，不帶第一輪的任何脈絡，任務是重新讀一次檔案、試著推翻它：程式碼真的存在嗎？這條路徑真的走得到嗎？被推翻的候選項目仍留在報告裡但會標註，看起來站得住腳的則停下來等人決定，絕不自動確認。靜態掃描器的發現項目跳過這一步，它們本來就是確定性的證據。
5. 概念驗證（PoC）（--poc，僅限 High 以上嚴重程度）。產生一份 PoC，放進容器沙盒裡跑（沒有網路、tmpfs、有硬性逾時）。找不到容器 runtime 時就把這個 PoC 記成已跳過，絕不會改到 host 上跑。

怎麼跑

duduclaw secaudit .                                   # 快速: 只跑掃描器
duduclaw secaudit . --profile deep --max-modules 5    # + AI 稽核與覆核
duduclaw secaudit . --poc --fail-on high --save       # + 沙盒化 PoC, 儲存報告

沒有東西達到 --fail-on 門檻（預設 high）時 exit code 是 0；有東西達到門檻是 1；只有基礎設施本身出錯才是 2——一台完全沒裝掃描器的機器一樣回 0，所以能乾淨接進 CI。被推翻與被抑制的發現項目仍然留在報告裡看得到，但不計入嚴重程度統計或關卡判定，所以對抗式覆核其實是在降低會讓建置失敗的雜訊。

--save 會把報告寫進 <home>/secaudit/reports/，儀表板會從這裡撿起來。

在儀表板覆核

安全稽核頁列出已儲存的報告，每一份報告依嚴重程度把發現項目分組，附一條可展開的證據鏈（靜態掃描命中、AI 推理過程、對抗式覆核的判定、任何 PoC 執行紀錄）。每個發現項目都帶三個覆核動作：確認、抑制、反駁，會寫回報告。這一頁受 manager 把關。

刻意留給你的部分

稽核本身從不會把一個發現項目標成已確認；看起來可信的項目會停在安全稽核頁等你決定。如果你稽核的是一個開源依賴，把漏洞回報給上游是一個對外的動作，這一步留給人。