安全与风控
用 AI 白盒渗透测试验证代码漏洞(带 PoC…
当需要对自己的代码库、仓库或 PR 做安全审计、找出可被真正利用的漏洞时,用 Strix 这类白盒 AI 安全审查工具读取源码、推理数据流与授权模型,并在沙箱中实际利用,产出带 PoC 的少量确证问题。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 38/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 59/100 ×0.15
适用场景
用 AI 白盒渗透测试验证代码漏洞(带 特定
解决思路
- 安装与 LLM 配置、全部参数、托管云路径见 penetration-testing-with-strix 技能;若不想用 Docker 也没有 LLM key,可用同一二进制走托管平台:先 `strix cloud login`,再 `strix cloud scans start ...`(细节见 managed-pentesting-with-strix)。
- 对本地工作树运行:`strix -n -t ./ --scan-mode standard --max-budget 15`。
- 直接扫描 GitHub 仓库:`strix -n -t https://github.com/org/app --max-budget 15`。
- 单体仓库(monorepo)只指向真正关心的服务,而不是整棵树:`strix -n -t ./services/checkout --max-budget 20`。
- 只审查某个分支改动的部分(大仓库全量审查很浪费):`strix -n -t ./ --scope-mode diff --diff-base origin/main --max-budget 10`。
- 注意本地路径会以可写方式挂载进沙箱,agent 可以修改它,因此要针对干净的 checkout 运行。
- 显著提升效果的做法一:额外提供一个正在运行的应用实例,例如 `-t ./ -t http://host.docker.internal:3000`,让 agent 能对活行为确认可利用性,从而把“看起来不安全”变成“已验证的发现”;若没有运行实例,纯静态发现应标注为未确认。
- 显著提升效果的做法二:限定审查范围,指向高风险子树并说明关注点,例如:`strix -n -t ./services/api --max-budget 15 --instruction "Focus on the authorization layer in src/auth and every route under src/routes/admin. Multi-tenant app: tenant id comes from the JWT. Flag any query that filters by object id without also filtering by tenant."`。
- 主动告知 agent 它无法可靠推断的信息:租户模型、信任边界、哪些输入是攻击者可控的。
- 若审查对象是 PR 而非整个仓库,用 ci-security-scanning-with-strix 做 diff 范围审查(含 PR 评论、SARIF 上传到 GitHub code scanning、按发现阻断合并);托管平台也可通过 API 直接审查 PR(见 managed-pentesting-with-strix)。
- 读取结果:在 `strix_runs/<run>/` 下,先看 `penetration_test_report.md`,再看 `vulnerabilities/*.md`(每条发现含 PoC 与修复建议)、`vulnerabilities.json` / `.csv`、`findings.sarif`(可上传到 code scanning)、`run.json`。
- 向用户汇报前,逐条打开发现,确认 PoC 确实证明了影响;报告时同时给出文件与行号以及利用方式,让修复一目了然。
- 退出码 `0` 只表示在被分析的部分没有证明可利用的问题,不代表代码库干净;要对照 `--max-budget` 检查 `run.json` 的状态与花费,并说明因预算上限而未审查到的路径。
- 把它当作互补工具而非全量清单:继续保留依赖扫描(SCA)和密钥扫描以覆盖已知 CVE 依赖与提交的凭据;本工具用于发现这些工具结构上找不到的逻辑、授权与注入类缺陷。
- 修复与验证:把结果交给 fix-security-vulnerabilities-with-strix,修根因(改共享的授权辅助函数,而不是只改那一个路由),然后重跑 Strix 证明漏洞不再可利用。
适用边界 · 注意事项
- 需要完整覆盖已知 CVE 依赖和已提交凭据时——应继续使用依赖扫描(SCA)与密钥扫描,本工具结构上无法穷尽这些。
- 没有运行中的应用实例时,静态发现只能算未确认,不能当作已验证漏洞上报。
- 不要对非干净 checkout 运行,因为本地路径会以可写方式挂载进沙箱,agent 可能修改文件。