開源工具把 vibe coding 變安全

我拆解一套適合資安工作的開源 vibe coding 工具鏈，最後給你可直接複製的安全工作流模板。

我用 AI 寫 code 有一陣子了，但在資安場景裡，它常常快得很心虛。你叫它補一段偵測腳本，它回你一套看起來很完整的東西，結果欄位名猜錯、輸入驗證漏掉、套件也挑得像沒看過你的供應鏈政策。那種感覺很煩，因為它不是完全不能用，是它太像一個會自信亂講的實習生。速度有了，判斷沒有。

所以我看到 Austin Miller 在 SecPro 這篇〈Which Open Source Tools Can Help Us with Vibe Coding in Cybersecurity?〉時，第一個反應不是「哇好酷」，而是「終於有人把工具和風險講在一起」。他點到的核心工具包括 OpenHands、Continue.dev、Aider、Open Interpreter、Ollama，再往上還提到 AutoGen、LangGraph、CrewAI 這種 agent 框架。

別把 vibe coding 當成比較會聊天的 autocomplete

What began as code completion and documentation assistance has evolved into a new development paradigm often described as vibe coding: a workflow in which developers express intent in natural language and allow AI systems to generate, modify, test, and sometimes deploy software on their behalf.

翻譯一下就是：這不是幫你補字而已，這是在幫你做事。差別超大。只要 AI 開始能生成、修改、測試，甚至執行部署，它就不再是鍵盤上的小幫手，而是工作流裡的一個執行者。資安工作最怕的就是這種「看起來很順」的東西，因為它會把錯誤包裝得像效率。

我之前叫它幫我做一個 Suricata log parser，結果程式長得像那麼回事，實際上卻默默假設分隔符永遠一致，還把壞資料直接丟掉。demo 看起來很漂亮，進到 investigation pipeline 就是另一回事。這也是我現在對 vibe coding 的態度：不是不能用，是你得先承認它在代你決定一些事。

實操上，我會先把任務切成三層：

• 低風險：樣板碼、測試、文件、一次性轉換腳本。
• 中風險：偵測規則、解析邏輯、內部工具、glue code。
• 高風險：production 變更、auth flow、secrets、對外服務。

低風險可以放手， 中風險要嚴審，高風險就別把方向盤整個交出去。這不是保守，這是知道模型最擅長的是補全，不是替你負責。

開源不是信仰，是你要得出來的帳

Miller 會把開源工具放在前面，我覺得很合理。資安團隊要的不是「某某廠牌說很安全」，而是你能不能看、能不能管、能不能自己收回來。封閉式工具常常不是不能用，而是你很難回答一個最基本的問題：資料到底去哪了？

翻譯一下就是，開源的價值不是浪漫，是可稽核。你可以看 prompt 怎麼處理、檔案怎麼讀寫、log 有沒有被留下、權限有沒有被放大。這些事情在敏感 repo、法規環境、或任何會讓法務皺眉的系統裡，都是硬需求，不是加分題。

我自己最在意的是它能不能接進既有控制。資安團隊本來就會做 identity、logging、container policy、SCA、egress control。AI 工具如果是開源的，我就能把它塞回這套框架裡；如果是黑盒子，我只能相信供應商的故事。老實說，我沒那麼好騙。

實操上，導入前我會問四件事：

• 能不能 self-host？
• 能不能看 prompt 和檔案的 code path？
• 能不能把 log 接進我自己的監控？
• 能不能限制它能讀、能寫、能執行什麼？

如果兩題以上答不出來，我就先把它當便利工具，不把它當資安工程工具。這個分類很重要，因為便利工具很容易偷偷跑進不該去的地方。

OpenHands 適合當 agent，不適合當聊天機器人

OpenHands 是我會優先看的東西，因為它不是只會回你一句建議。它是偏 autonomous 的軟體工程平台，可以規劃步驟、執行命令、瀏覽文件、操作 repo，然後自己繼續迭代。這跟一般 assistant 差很多，後者像會講話的 autocomplete，前者比較像能自己跑流程的 junior。

OpenHands is an autonomous software engineering platform that allows AI agents to write code, execute commands, browse documentation, interact with repositories, and perform multi-step development tasks.

也就是說，如果你給它的是「做一個 log ingestion pipeline」這種任務，它不只是在等你每一步都手把手餵，而是會自己拆步驟、跑命令、修錯、再試一次。這在資安工作裡很有用，尤其是那些重複但還是有點複雜的事：產生測試資料、寫驗證腳本、接 parser、補文件、修掉第一版的 bug。

我會把 OpenHands 用在有明確終點、而且環境可以丟掉的工作。sandbox 裡的任務很適合，因為 agent 亂跑的成本低；如果你把它丟到 live system，還希望它自己懂分寸，那你是在等事故。

實操寫法很簡單：只拿它做多步驟、可回收、可丟棄的任務。

• 把 incident note 變成偵測 pipeline 草稿
• 為新的 log source 做 parser proof-of-concept
• 產生 test fixture 和 validation script
• 幫內部工具打地基，但最後還是人審

我的判斷標準是：如果任務需要規劃、迭代、執行命令，OpenHands 很適合；如果任務牽涉商業風險判斷，就不要讓它自己決定下一步。

Continue.dev 是比較像樣的 IDE 夥伴

不是每個人都想要一個會自己亂走的 agent。很多資安工程師要的是「幫忙，但不要搶方向盤」。這時候 Continue.dev 反而更實際。它跑在 VS Code 和 JetBrains 裡，可以接本地或遠端模型，重點是它還是待在你熟悉的 IDE 裡，不會把整個工作流搞得像新創 demo。

翻譯一下就是，Continue 比較像同事，不像外包。它可以幫你補 code、解釋怪函式、建議 refactor、寫測試、看安全敏感函式，但你還是坐在駕駛座。這點很重要，因為一旦 code 牽涉 auth、secrets、infra，你就不想讓工具自己發揮。

我特別喜歡它拿來做 detection engineering 和內部工具。像我在改 SIEM integration 或調 Sigma rule set 的時候，我不想要一個會自作主張「幫我做完」的東西，我要的是 inline help、可以選模型、而且 repo 還是由人控制。

實操上，我會在這些情況用 Continue：

• 團隊已經習慣在 IDE 裡工作
• 想保留 code review 習慣
• 敏感專案想用 local model
• 不想把 source code 丟給第三方

如果 OpenHands 是能幹活的 agent，那 Continue 就是比較不吵的助理。對很多資安團隊來說，這反而是比較好的第一步。

Aider 是給 Git 腦的人用的

Aider 很對我胃口，因為它就是從 terminal 出發，直接理解 repo 結構，然後把修改落到 tracked files 上。這聽起來沒什麼，但這正是它適合資安工作的原因：它沒有假裝你不需要 Git。

Aider operates directly from the command line and allows developers to use AI models to modify existing repositories.

也就是說，它尊重正常開發流程。你看得到 diff、可以 review commit、可以保留稽核軌跡。資安裡面這不是加分，是基本盤。你不可能一邊要求可追蹤，一邊又把改動藏在一層 opaque 的互動介面裡，然後說自己很嚴謹。

我自己很吃 terminal-first workflow，因為它讓事情比較容易留下紙本紀錄。當我叫 AI 工具碰 repo，我要的是最後能像一般改動一樣出現在 diff 裡，而不是一坨難以說明的魔法。Aider 在這點上做得很好，特別適合擴充內部 recon tool、加 protocol parser、或把重複資料處理自動化。

實操寫法就是：只要你們本來就靠 Git review，Aider 就很合適。

• 跨多檔的小型 refactor
• 替既有 code 補測試
• 更新 parser 和 transform
• 逐步改進、逐步 review 的變更

最大的好處是透明。模型做錯，你在 diff 就抓得到，不會等到 merge 後才知道它把東西弄歪了。這種安全網，資安團隊應該很熟悉，也應該很愛。

Open Interpreter 很強，所以更要綁好手腳

Open Interpreter 的重點不是產生 code，而是把自然語言直接接到本機操作。它能跟本地環境互動、執行命令，這讓它很適合自動化，但也代表你給了它比純文字 assistant 多很多權限。

翻譯一下就是，它不只是在寫，它是在做。這對某些 operational security 工作很方便。像我如果要解析 firewall logs、做 enrichment、再輸出報告，我可以直接描述結果，讓它幫我協調步驟。重複、局部、可控的工作，這種工具很好用。

但風險也很明白：一旦工具能動系統，你就得先想好邊界。sandbox、權限控管、logging，這三個少一個都不行。我不會把它丟進 production 環境，還期待它自己知道什麼叫節制。

實操上，我只會把 Open Interpreter 放在 blast radius 很小的地方：

• 工作站上的 log parsing 和 enrichment
• 離線資料的報告產生
• 批次檔案轉換
• 不需要高權限的內部腳本

如果你想要自然語言的速度，又不想完全失控，它可以很有用。但只要它開始拿到真正的權限，責任就回到你身上了。

Ollama 讓本地模型變成真的，不只是口號

開源 vibe coding stack 最實際的一步，就是把模型也拉回本地。這也是 Ollama 重要的原因。它讓你不用把 source code 丟去第三方服務，也能在自己的硬體上跑模型。

也就是說，你的 code、prompt、context 可以留在自己環境裡。對醫療、金融、政府、國防這種本來就很在意資料流向的場景，這不是漂亮話，這是能不能上線的差別。

我自己最常把 local model 用在敏感 repo 或內部資料。你還是要管品質、管安全，但至少不會為了拿到 AI 建議，又額外多開一個資料外洩面。這種帳我比較不想算。

實操上，我會把 Ollama 跟 Continue 或 Aider 綁在一起：

• 用 Ollama 跑 local model
• 在 VS Code 或 JetBrains 裡接 Continue.dev
• 用 Aider 做 Git-based repo edits
• 敏感專案不要碰 hosted endpoint

這套不會解決所有問題，但它至少讓你在治理、隱私、內部審查上比較站得住腳。資安很多時候不是比誰最炫，是比誰說得清楚。

agent 框架不是萬能，是給你分工用的

如果團隊已經玩到 assistant 這層，再往上走通常就是分工。Miller 提到 AutoGen、LangGraph、CrewAI，我覺得方向是對的。這些框架的價值，不是讓一個模型更聰明，而是讓多個 agent 各做各的。

These frameworks enable developers to create specialised agents with distinct responsibilities.

翻譯一下就是：不要再逼一個 bot 同時當分析師、審查員、法遵、硬化工程師。這種幻想很貴，而且通常不好維護。資安本來就是高度分工的工作，agent 框架只是把這件事搬到 AI workflow 裡而已。

但我會很保守地用它。前提是你已經把 model governance、prompt 邊界、logging、human review 這些基本功弄好。否則你只是把流程變得更複雜，最後出事時還更難查。這種系統看起來很先進，實際上只是更難 audit。

實操上，我會把它用在重複、可量化、角色清楚的流程：

• agent-based secure code review
• 漏洞 triage pipeline
• merge 前的 policy check
• 有明確分工的 threat research workflow

我的建議很土，但有效：先做一條窄流程，先看一個指標。它如果連這條都改善不了，就先別急著把整個團隊流程丟進去。

開源不等於安全，AI 生成碼還是會咬人

Miller 這篇我最認同的一點，是他沒有把開源講成免死金牌。AI 生成碼本來就有風險，研究一直在抓 insecure pattern，AI-assisted 開發環境也有自己的坑：prompt injection、資料外洩、甚至某些情境下的 remote code execution。

也就是說，工具開源不代表你可以放棄基本功。它跑在本地，不代表它寫出來的 code 就安全；它回覆得很像樣，不代表它真的理解你的風險模型。尤其是 dependency，模型很愛亂推薦，你不查就等著踩雷。

實操上，我會把 AI-assisted coding 當成任何高風險自動化來管：

• merge 前一定 review 生成碼
• 掃 dependency，版本要鎖死
• 需要時記錄 prompt 和工具動作
• 能 sandbox 就 sandbox
• 敏感專案和實驗環境分開

如果要我把整篇收斂成一句話，我會說：開源 vibe coding 工具在資安裡有用，是因為它讓你在保留控制權的前提下加速；但控制權不能靠感覺，得靠制度。

可抄的模板

# Secure vibe coding stack for cybersecurity teams（可直接貼到團隊內部文件或 README）

## 1) 先選互動模式
- 用 OpenHands 做多步驟、可丟棄環境的 agent 任務
- 用 Continue.dev 做 IDE 內的協作
- 用 Aider 做 Git-first 的 repo 修改
- 只有在本機、低風險自動化時才用 Open Interpreter

## 2) 再選模型位置
- 敏感 codebase：優先用 Ollama 跑 local model
- 非敏感、低風險工作：才考慮 hosted model

## 3) 先把 guardrails 寫死
- 敏感 repo 只放在 self-hosted 環境
- 所有 AI 產生的變更都要 human review
- 記錄 prompts、tool actions、file changes
- 任何能執行命令的工具都要 sandbox
- 限制網路、檔案系統、credential 存取

## 4) 把工具和任務對齊
### 適合交給 AI 的工作
- detection rule 草稿
- log parser
- 內部 utility script
- test generation
- documentation
- 小型 refactor

### 不要放手太多的工作
- auth flow
- secrets handling
- production changes
- internet-facing service
- privileged automation

## 5) 建議的起手式
1. 用 Ollama 跑一個 local model
2. 在 VS Code / JetBrains 接 Continue.dev
3. 用 Aider 做需要乾淨 diff 的 repo 修改
4. 把 OpenHands 放在 sandbox 裡處理 bounded agent tasks
5. 所有變更都走 Git review 和既有資安檢查

## 6) 團隊政策句
"AI-assisted code may accelerate implementation, but it does not replace review, testing, dependency checks, or security approval for sensitive changes. Any tool that can read, write, or execute must be scoped to the minimum access required for the task."

## 7) 實用 prompt 模板
"Build [task] for [environment]. Use [language/tooling]. Keep the implementation minimal, include tests, avoid external dependencies unless necessary, and explain any security tradeoffs before making changes."

這套我會拿來當資安團隊的第一版標準流程。它故意很無聊，因為在會碰到敏感系統的地方，無聊通常就是好事。

我這篇大部分是根據 Austin Miller 在 SecPro 的原文做拆解，工具清單與基本框架主要來自 Which Open Source Tools Can Help Us with Vibe Coding in Cybersecurity?。我加進去的是我自己的排序、風險切法和可直接抄的工作流模板，讓你不用自己再把零件拼一次。