SEC-AF
基于 AgentField 的 AI 原生代码安全审计器，不只会标记可疑模式，而是通过数据流追踪和证据证明漏洞是否真实可利用。
- Star 数
- ★ 199
- 最近更新
- 1 个月前
- License
- Apache-2.0
- 主语言
- Go
- FA 评分
- 58/100 · 缺口较多
30 秒速览
- 可在哪里用
- 通用 · 跨平台Codex · Claude Code
- 开始前需要
- 典型场景
- 开发团队在合并前对 GitHub 仓库做带验证的 SAST 审计，避免传统扫描器的大量误报，可通过 GitHub Actions 集成并上传 SARIF 到 Code Scanning。
- 主要局限
- 强依赖 AgentField 生态与 OpenRouter：需要运行控制平面、af CLI 和 OPENROUTER_API_KEY，默认模型指向 OpenRouter 上的特定模型。
这个 Agent 能做什么，适合哪些场景？
SEC-AF 是运行在 AgentField 控制平面上的 AI 原生安全审计 Agent，仓库为 Agent-Field/sec-af，采用 Apache-2.0 许可证。它通过一次 API 调用（sec-af.audit）对目标 GitHub 仓库执行审计，内部由约 200–300 个聚焦的 LLM reasoner 组成有向无环调用图，覆盖 RECON、HUNT、DEDUP、PROVE、REMEDIATION 五个阶段。每个发现都附带裁决（confirmed / likely / inconclusive / not_exploitable）、完整污点数据流追踪和精确代码位置，并支持 SARIF 2.1.0、JSON 和 Markdown 输出，可映射 PCI-DSS、SOC2、OWASP、HIPAA、ISO27001 合规框架。在 DVGA 基准上，它把 106 个原始发现压缩到 28–30 个经验证发现，噪声降低 94%，一次标准审计成本约 $0.18–$0.90（Kimi K2.5 经 OpenRouter）。它以 SAST 为主，不覆盖运行时/协议层攻击（如 GraphQL 批量查询、深递归），目前通过 Docker Compose、Railway 一键部署或 af install 安装，维护版本为 Go 实现，Python 实现仍可用。
SEC-AF 接收 repo_url 等参数，克隆目标仓库后执行五阶段流水线：RECON 阶段并行梳理架构、依赖、数据流与安全上下文；HUNT 阶段由 AI 门控动态选择并运行 10+ 个专用策略 hunter（注入、加密、认证等）；DEDUP 阶段先指纹去重再语义去重；PROVE 阶段对每个发现运行 4 个对抗性子 Agent（tracer 重建数据流、sanitization analyzer 查找缓解措施、exploit hypothesizer 构造攻击场景、verdict agent 综合裁决）；REMEDIATION 阶段为确认的发现生成修复建议。调用方式包括 af call sec-af.audit --in '{"repo_url": ...}' 或 POST http://localhost:8080/api/v1/execute/async/sec-af.audit，可通过 depth（quick/standard/thorough）、scan_types、severity_threshold、max_cost_usd、include/exclude_paths 等参数定制。输出包含 verdict、proof（含 data_flow_trace）、location 和 SARIF/JSON/Markdown 报告。
- 开发团队在合并前对 GitHub 仓库做带验证的 SAST 审计，避免传统扫描器的大量误报，可通过 GitHub Actions 集成并上传 SARIF 到 Code Scanning。
- 安全工程师审计 GraphQL 应用（如 DVGA 类项目），获取命令注入、SQL 注入、SSRF、认证绕过等类别的确认发现及污点追踪证据。
- DevSecOps 团队需要合规映射报告，选择 pci-dss、soc2、owasp、hipaa 框架生成审计输出。
- 开源维护者以极低成本（约 $0.10–$0.40 的 quick 档）对项目做快速安全体检，2–5 分钟出结果。
- AgentField 用户已运行控制平面，通过 af install https://github.com/Agent-Field/sec-af 将审计能力作为节点接入现有 Agent 编排体系。
- 安全研究员希望自定义漏洞类别，通过添加一个 hunter 文件扩展新的漏洞类型，由编排器自动发现并纳入去重—验证流水线。
如何安装或部署这个 Agent？
方式一（已有 AgentField）：af install https://github.com/Agent-Field/sec-af && af run sec-af，首次运行会提示输入 OPENROUTER_API_KEY（加密存储）。方式二（Docker Compose）：git clone https://github.com/Agent-Field/sec-af.git && cd sec-af && cp .env.example .env（填入 OPENROUTER_API_KEY）&& docker compose up --build。方式三（Railway 一键部署）：使用 README 中的 Railway 部署按钮，需提供 OPENROUTER_API_KEY。方式四（本地 Python）：Python 3.11+ 环境下 git clone 仓库、python3 -m venv .venv && source .venv/bin/activate、pip install -e .、cp .env.example .env 填入 OPENROUTER_API_KEY，然后一个终端运行 af server，另一个运行 python3 main.py。注意：维护版本为 go/ 目录下的 Go 实现（默认端口 8013），Python 版可通过 python -m sec_af.app 或本地路径安装使用。
如何使用这个 Agent？
最简调用：af call sec-af.audit --in '{"repo_url": "https://github.com/dolevf/Damn-Vulnerable-GraphQL-Application"}'（要求 af ≥ 0.1.87），或 curl -X POST http://localhost:8080/api/v1/execute/async/sec-af.audit -H 'Content-Type: application/' -d '{"input": {"repo_url": ...}}'，随后用 GET /api/v1/executions/<execution_id> 轮询结果。可选参数包括 branch、depth（quick/standard/thorough）、severity_threshold、scan_types（sast/sca/secrets/config）、output_formats（sarif//markdown）、compliance_frameworks、max_cost_usd、max_provers、max_duration_seconds、include_paths、exclude_paths。关键环境变量：AGENTFIELD_SERVER（默认 http://localhost:8080）、OPENROUTER_API_KEY（必需）、HARNESS_MODEL 与 AI_MODEL（默认 deepseek/deepseek-v4-flash-0731，可切换任意 OpenRouter 兼容模型）、HARNESS_PROVIDER（默认 aforge）。CI 中可在 GitHub Actions 触发审计并将 SARIF 上传至 GitHub Code Scanning。
这个 Agent 有哪些优点和局限？
- 对抗性验证架构：HUNT 与 PROVE 阶段结构分离，每个发现经 4 个子 Agent 验证链（追踪、净化分析、攻击构造、裁决），DVGA 基准实现 94% 噪声降低。
- 每个发现附可操作证据：verdict、完整污点数据流追踪、精确代码位置，而非模糊的『可能有问题』。
- 成本透明且低廉：一次含 30 个已验证发现的标准审计约 $0.18–$0.90（Kimi K2.5），并有公开的评分公式和深度档位定价参考。
- 可组合与可观测：新增漏洞类别只需添加一个 hunter 文件；所有 reasoner 调用经控制平面形成完整 DAG，可审计每个阶段的耗时与推理内容。
- 原生 SARIF 2.1.0 输出与 GitHub Actions 集成路径，且支持多种合规框架映射。
- 强依赖 AgentField 生态与 OpenRouter：需要运行控制平面、af CLI 和 OPENROUTER_API_KEY，默认模型指向 OpenRouter 上的特定模型。
- 仅覆盖 SAST：无法检测 README 明确列出的 GraphQL 协议层攻击（批量查询、深递归、别名滥用、内省暴露等），协议级检测仍在路线图中。
- 审计耗时可观：standard 深度在 DVGA 上约 78 分钟、约 166–255 次 Agent 调用、82 个 DAG 边，thorough 档 30–120 分钟。
- 结果中存在 inconclusive 裁决仍需人工复查，且基准中 1 个场景被正确拒绝的同时也说明验证链并非完美。
- 双实现（Go 为主、Python 备用）带来迁移注意点：af install 裸仓库 URL 会安装 Go 版并替换旧 Python 版，本地路径安装则不遵循 superseded_by。
这个 Agent 与同类方案有什么区别？
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|
| SEC-AF 当前 | 58 · 缺口较多 | ★ 199 | 1 个月前 | Go | Codex · Claude Code |
| ControlKeel | 59 · 缺口较多 | ★ 11 | 今天 | Elixir | Codex |
| AWS Agent Toolkit | 58 · 缺口较多 | ★ 2.7k | 今天 | Python | Codex · Claude Code |
| Cloudflare 安全审计技能 | 52 · 缺口较多 | ★ 21k | 10 天前 | JavaScript | — |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
README 显示工具会克隆用户指定的仓库并把代码发送给第三方 LLM（OpenRouter），但所提供的源文件中未见最小权限、沙箱、用户确认或数据流说明；API 密钥据称加密存储仅是安装文档的断言。无回滚机制说明。得分：多数信任准则仅 1 分（有相关行为可推断但无支持性文件），rollback 0 分（完全无证据）。source_attribution 2 分：LICENSE 与作者信息齐全，但发布者未经注册表验证。
README 内部数字存在不一致：基准表写 '28 confirmed'，随后多处写 '30 verified findings'，扣分至 1。依赖数量少且有 CI 构建/测试 Go 实现，dependency_availability 2。failure_messages 仅在 verdict 模型中定义 inconclusive，缺少错误与失败路径文档，1 分。
能力边界是本项目最突出的一项：README 明确说明当前仅限 SAST、列出 9 个未覆盖场景及原因，得 3。受众与场景清晰但偏单一（GraphQL/Python 示例），触发精度与多环境支持（Docker/Railway/Go/af）描述充分但未经执行验证，各 2 分。
信息架构与安装说明非常完整（af install、Docker、本地步骤、Go 实现说明），known_limitations 有专门章节，license 为完整 Apache-2.0，均 3 分。naming_stability 2 分：对 superseded_by 与 node id 有明确处理但涉及实现细节。versioning_changelog 1 分：仅 0.1.0，无 CHANGELOG。maintenance_responsibility 1 分：发布者身份未验证，无治理或维护承诺文件。
输出可用性突出：verdict、proof、数据流轨迹、SARIF 2.1.0、合规映射均有 schema 与示例支撑，3 分。marginal_value 与 cost_benefit 各 2 分：与 Semgrep/CodeQL 的对比有诚实的让步说明，成本估算有依据，但均为静态声明，未独立核实，且存在 28/30 计数矛盾。
claim_traceability 2 分：基准结果与性能分析指向 exampl/ 文件（注意目录名拼写 'exampl' 疑似笔误）。cross_source_corroboration 1 分：所有性能与效果声明均来自自报基准，无第三方佐证。fact_inference_separation 2 分：成本标为估算、对比表附来源免责声明，但部分声明仍混合推断。
- 源码中未见：回滚或恢复路径运行前先备份，或在 git 分支、快照上操作，确保改动可以撤销。
- 信任维度证据薄弱：未提供沙箱、最小权限或目标仓库代码外发至第三方 LLM 的数据处理说明，使用前请自行评估代码外泄风险。
- README 中 '28 confirmed' 与 '30 verified findings' 数字矛盾，且全部效果声明来自自报基准，未经独立核实（本次为静态审查，置信度为低）。
- 无版本变更日志且发布者未经注册表验证，升级与维护路径不确定。
- 回滚机制完全无文档；若部署到生产环境需自行准备恢复方案。