別只讓 AI 寫程式：用 Strix 把 AI 變成會驗證漏洞的自動化滲透測試團隊

如果團隊已經讓 AI 參與寫程式，下一個很實際的問題就是：誰來確認這些程式真的安全？傳統 SAST 或依賴掃描很適合找出已知模式，但它們不一定能把一條跨頁面、跨權限、跨 API 的攻擊路徑走完。人工滲透測試則能補足這個缺口，卻通常昂貴、耗時，也很難在每個 Pull Request 都執行。

Strix 的切入點，是把 AI agent 放進滲透測試流程，而不是只讓模型讀幾段程式碼後列出可能問題。官方將它定位為開源 AI penetration testing tool；README 描述的核心流程包含動態執行程式、尋找漏洞，並用實際的 proof of concept 驗證結果。[2] GitHub repo 頁面在本次查證時顯示 51,208 個 stars。[1]

我的判斷很簡單：Strix 值得看的地方，不是「AI 會不會取代資安專家」，而是它把偵察、嘗試、驗證、報告與修補重測串成一條開發者可以啟動的 CLI 工作流。只要把授權範圍、模型成本與寫入權限管好，它比單純的 AI code review 更接近真正的安全驗證。

先講結論：Strix 解決的是「安全回饋太晚」

Strix 不是把漏洞資料庫換成聊天介面，也不是一個只會產生掃描報告的黑盒服務。它提供的是一個由多個 AI pentester agents 協作的執行環境，能使用瀏覽器、HTTP proxy、shell、Python sandbox，以及靜態與動態分析工具。這種設計的價值，在於漏洞往往不是單一檔案中的一行錯誤，而是需要先理解應用流程，再建立可重現的攻擊路徑。

官方 README 把能力分成幾個方向：偵察、利用與驗證組成的 pentesting toolkit，多代理人協作，真實 exploit validation，以及帶有修補建議的 developer first CLI。[2] 這些詞不代表每次掃描都會得到正確答案；它們比較像是產品設計目標。實務上，我會把 Strix 的輸出當成需要工程師複核的安全證據，而不是可以直接合併的裁決。

這也是它和一般 AI code review 的重要差異。Code review 常回答「這段程式看起來可能有問題」，Strix 嘗試回答「我能否在這個有範圍的目標中重現問題，並留下可供修補與重測的線索」。對開發團隊來說，後者更接近可執行的 issue。

架構看法：不是一個 agent，而是一個受控的 agent runtime

從使用者角度看，Strix 是 CLI；從執行模型看，它更像是把 AI agent、工具容器與掃描工作目錄包在一起的 runtime。官方列出的工具包含 Playwright 驅動的瀏覽器、可攔截與重播請求的 HTTP proxy、shell、Python exploit runtime，以及預先準備的安全工具。[2]

這裡有三個值得注意的設計：

工具比 prompt 更重要。 Agent 能不能找到漏洞，取決於它能否觀察應用、送出請求、保存狀態與驗證結果，而不只是模型本身的推理能力。
驗證比猜測更重要。 將 finding 連到 reproduction steps 或 PoC，能讓工程師判斷嚴重度，也讓修補後的重測有明確目標。
範圍比自主性更重要。 自動化安全工具可以跑得很快，但它同時也可能碰到不該碰的資料或服務。因此 target、instruction、scope 與執行環境必須先被設計好。

Strix 也支援多個 LLM provider。官方文件指出，它透過 LiteLLM 做模型相容層，支援超過 100 個 LLM providers，也能設定本地模型。[7] 這讓團隊可以依照成本、資料敏感度與推理品質調整模型，不必把整個安全流程綁死在單一 API。

如何開始使用：先在本機、可回復的目標上驗證

我不建議第一次就把正式網域交給 autonomous pentesting agent。更穩妥的路徑，是先準備一個你擁有的本機測試專案或專門的 staging 環境，確認 Docker、模型設定、輸出位置與授權文件都沒有問題。

1. 準備環境

官方 Quick Start 列出的前置條件是正在執行的 Docker，以及任一支援 provider 的 LLM API key。[3] 如果資料不能離開內網，文件也提供 local model 的設定方向；但本地模型是否有足夠的工具使用與長鏈推理能力，仍要用自己的 target 做評估。

先確認 Docker：

docker version

再安裝 Strix。官方 README 的安裝方式是使用安裝腳本；在企業環境中，我會先把腳本下載下來審查，再交給內部套件管理流程，而不是在 production runner 上盲目執行遠端內容。

curl -sSL https://strix.ai/install | bash

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="在安全的 secret manager 中注入"

上面的 API key 只是佔位說明，不要把真實憑證寫進 shell history、GitHub Actions YAML 或 repository。Strix 會保存 CLI 設定；官方 README 提到預設位置是 ~/.strix/cli-config.json。[2] 這個檔案也應列入主機權限與備份政策檢查。

2. 執行第一個本機掃描

先從你擁有的測試程式目錄開始：

strix --target ./your-app

首次執行會自動拉取 sandbox Docker image，結果則保存到 strix_runs/<run-name>。[3] 這個行為很適合拿來建立可重現的驗證流程：每次執行保留 target、模型、scan mode 與輸出，工程師再針對 finding 做人工複核。

完成後可以用內建 viewer 檢視最近一次結果：

strix view

官方 README 說明，viewer 會啟動綁定在 127.0.0.1 的本機服務，直接從磁碟讀取 run files，不需要雲端帳號或上傳。[2] 對含有敏感程式碼的本機測試而言，這是比先把完整報告推上第三方服務更容易控制的方式。

3. 明確指定掃描範圍與模式

Strix 的 target 不只可以是本機目錄，也能是 repository、URL、domain、IP、OpenAPI 或 Postman collection。[4] 但「能測」不等於「應該測」。每一個非本機 target 都要先完成資產擁有權與測試授權確認。

官方文件提供 quick、standard、deep 三種 scan modes，用來在速度與完整度之間取捨。[5] 我的建議是：

Pull Request 先用 quick，只處理變更範圍，讓回饋時間可控。
Staging 每日或每週用 standard，觀察跨模組與跨流程問題。
重大版本或正式上線前再安排 deep，並預先設定預算、時間與人工值守。

例如先用 headless quick scan 驗證 CLI 能否在自動化環境結束並回傳結果：

strix -n --target ./your-app --scan-mode quick

-n 是 non interactive 模式，適合 server 或自動化工作；官方說明指出，發現漏洞時 CLI 會以 non zero exit code 結束。[2] 這讓 CI 可以把結果接到後續 gate，但也要先確認團隊想要的是「任何 finding 都阻擋」還是「只有高嚴重度 finding 阻擋」。

接進 CI：讓安全檢查靠近變更，而不是靠近事故

Strix 官方提供 GitHub Actions 範例，在 Pull Request 中安裝工具並使用 quick 掃描。[6] CI 工作流需要 fetch-depth: 0，因為 Strix 要用完整 Git history 做 diff scope；如果 diff 無法解析，也能用 --diff-base 明確指定比較基準。[2]

一個不把憑證寫死的最小骨架如下：

name: strix-security-scan

on:
  pull_request:

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - name: Install Strix
        run: curl -sSL https://strix.ai/install | bash

      - name: Run Strix
        env:
          STRIX_LLM: ${{ secrets.STRIX_LLM }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
        run: strix -n --target ./ --scan-mode quick

正式導入前，我會補上四件事：

將 STRIX_LLM 與 LLM_API_KEY 放在 GitHub Actions secrets，並限制 workflow 的權限。
先用非阻擋模式收集一段時間，建立誤報與成本基線。
對 scan artifact 設定保留期限，避免把 source code、請求內容或 PoC 長期暴露。
把 finding 對應到 owner、修補期限與 re-scan 流程，而不是只把失敗標記丟回 PR。

真正的坑：agent 有寫入權限，也可能有破壞性

這是我認為最需要被放在文章中央的提醒。官方 CLI 文件明確說明，本機目錄會以可寫入方式掛載到 sandbox，agent 可能修改實際檔案；文件因此要求執行前先 commit 或 stash。[4] 這表示 Strix 不應被當成單純 read only scanner。

實務上至少要做這些隔離：

只給專用測試分支或乾淨 checkout，不要直接指向未提交的工作目錄。
測試資料使用假資料，避免 agent 讀到 production secrets、個資或支付資訊。
網路出口設白名單；外部 URL 測試要有書面授權、明確 scope、時間窗與停機聯絡人。
對模型 provider 做資料流盤點，確認 prompt、source code、請求與 finding 是否會離開內網。
將 strix_runs 當成敏感安全資料處理，設定檔與報告都使用最小權限。

README 也用警告文字要求只測試自己擁有或有明確書面授權的系統，並留在約定範圍內。[2] 這不是附註，而是工具能否被企業採用的前提。自動化不會替團隊取得授權，也不會替團隊承擔誤測第三方系統的法律與營運風險。

Strix 適合誰，不適合誰

適合先試的團隊：

已有 Docker 與 CI 基礎，想把動態安全檢查放進開發週期。
有明確 staging 或測試資產，能先建立合法且可回復的 target。
願意讓資安與開發共同定義 finding 的嚴重度、修補 SLA 與重新掃描條件。
想比較雲端模型、本地模型與不同 scan mode 的成本品質，而不是只追求一次性的 demo。

不適合直接導入的情況：

沒有資產清單、沒有授權流程，卻想對網際網路任意目標執行。
期待 agent 自動替代人工安全審查，或把每個 finding 當成絕對正確。
CI runner 沒有隔離，工作目錄中含有 production secrets 或未備份的本地修改。
沒有模型成本上限、報告保留政策與事件回應窗口。

我的導入順序

如果今天要把 Strix 放進一個 AI 應用團隊，我會分成四個階段：

第一階段只測本機故意設計的測試專案，確認 Docker、LLM、sandbox、viewer 與 artifact 都能工作。第二階段在 staging 對單一 API 或應用執行 standard scan，人工檢查 finding 是否能重現。第三階段把 quick scan 放進 Pull Request，但先只留言不阻擋，持續觀察成本、耗時與誤報。第四階段才對高信心且高風險的 finding 設定 gate，並把修補後重測納入 Definition of Done。

這個順序看似保守，卻能避免「因為 demo 很酷，所以直接把自主 agent 接到 production」的常見錯誤。安全工具的成熟度，最後不是由它能發出多少 finding 決定，而是由團隊能否安全地驗證、修補、追蹤與重現決定。

結論：AI 安全工具的價值，在於縮短驗證迴圈

Strix 最值得關注的地方，是它把 AI agent 從程式碼旁邊的評論者，推向能操作工具、探索應用並驗證結果的測試執行者。這個方向很符合 AI engineering 的核心問題：如何把模型能力嵌進可靠、可觀測、可回復的工程流程。

但我不會把它包裝成自動化安全的終點。它仍然需要正確的 target、授權、模型、隔離、預算與人工判斷。對多數團隊來說，最合理的第一步不是掃描正式環境，而是用一個可回復的 staging target 跑完第一次完整流程，再把最小化的 quick scan 接進 PR。

如果你的團隊已經在使用 AI 寫程式，下一個成熟度問題就不該只是「如何讓 AI 寫得更快」，而是「如何讓 AI 寫出的東西更快被安全地驗證」。Strix 提供了一條值得實驗的開源路徑。

Sources

[1] https://github.com/usestrix/strix

[2] https://raw.githubusercontent.com/usestrix/strix/main/README.md

[3] https://docs.strix.ai/quickstart.md

[4] https://docs.strix.ai/usage/cli.md

[5] https://docs.strix.ai/usage/scan-modes.md

[6] https://docs.strix.ai/integrations/github-actions.md

[7] https://docs.strix.ai/llm-providers/overview.md