别只让 AI 写程式：用 Strix 把 AI 变成会验证漏洞的自动化渗透测试团队
# 别只让 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]
这里有三个值得注意的设计：
1. **工具比 prompt 更重要。** Agent 能不能找到漏洞，取决于它能否观察应用、送出请求、保存状态与验证结果，而不只是模型本身的推理能力。
1. **验证比猜测更重要。** 将 finding 连到 reproduction steps 或 PoC，能让工程师判断严重度，也让修补后的重测有明确目标。
1. **范围比自主性更重要。** 自动化安全工具可以跑得很快，但它同时也可能碰到不该碰的资料或服务。因此 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：
```bash
docker version
```
再安装 Strix。官方 README 的安装方式是使用安装脚本；在企业环境中，我会先把脚本下载下来审查，再交给内部套件管理流程，而不是在 production runner 上盲目执行远端内容。
```bash
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. 执行第一个本机扫描
先从你拥有的测试程式目录开始：
```bash
strix --target ./your-app
```
首次执行会自动拉取 sandbox Docker image，结果则保存到 `strix_runs/`。[3] 这个行为很适合拿来建立可重现的验证流程：每次执行保留 target、模型、scan mode 与输出，工程师再针对 finding 做人工复核。
完成后可以用内建 viewer 检视最近一次结果：
```bash
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 能否在自动化环境结束并回传结果：
```bash
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]
一个不把凭证写死的最小骨架如下：
```yaml
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
```
正式导入前，我会补上四件事：
1. 将 `STRIX_LLM` 与 `LLM_API_KEY` 放在 GitHub Actions secrets，并限制 workflow 的权限。
1. 先用非阻挡模式收集一段时间，建立误报与成本基线。
1. 对 scan artifact 设定保留期限，避免把 source code、请求内容或 PoC 长期暴露。
1. 把 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