nb1b3k/SecureFlow-AI
GitHub: nb1b3k/SecureFlow-AI
SecureFlow-AI 是一个智能 DevSecOps PR 安全审查工具，将确定性安全扫描器与 LLM 驱动的推理相结合，在 pull request 阶段自动发现漏洞、生成安全评估并做出 CI 门禁决策。
Stars: 3 | Forks: 0
# SecureFlow AI
一个智能 DevSecOps 审查工具，在每个 pull request 上运行。它将确定性安全扫描器与 LLM 驱动的推理相结合，生成结构化审查评论、SARIF 报告和 CI 门禁决策（`PASS` / `WARN` / `FAIL`）。
确定性侧处理扫描器擅长的领域：密钥检测、SAST 模式、依赖项 CVE 和 IaC 配置错误。LLM 侧处理扫描器遗漏的部分：业务逻辑缺陷、授权缺口、设计级威胁（STRIDE）、可利用性推理和补丁生成。最终的策略决策始终由确定性 Python 做出；LLM 输出仅供参考。
## 架构
```
flowchart TB
PR([PR event]) --> CTX[context_agent
diff + sensitive-file detection] CTX --> SEC[secrets_scan
Gitleaks] CTX --> SAST[sast_scan
Semgrep] CTX --> DEP[dependency_scan
Grype] CTX --> IAC[iac_scan
Checkov] CTX --> AID[ai_discovery
LLM] SEC & SAST & DEP & IAC & AID --> NORM[normalize
dedup + scope filter] NORM --> THM[threat_mapping
CWE / OWASP / ATT&CK] THM --> ENR[enrichment
OSV / CVSS] ENR --> REACH[reachability filter] REACH --> EXP[exploitability
LLM second-opinion] EXP --> PATCH[patch_generation
LLM + git apply + scanner rescan + LLM review] EXP --> TM[threat_model
STRIDE delta LLM] PATCH & TM --> DEC[policy engine
PASS / WARN / FAIL] DEC --> OUT([JSON · Markdown · SARIF · PR comment]) classDef llm fill:#fef3c7,stroke:#d97706 class AID,EXP,PATCH,TM llm ``` 使用 LLM 的节点已着色标注。每次 LLM 调用都经过以下环节： - 跨提供商故障转移链，以便在遇到速率限制、模式验证失败和配额耗尽时自动路由到下一个提供商。 - 基于内容寻址的缓存，键值为 `(prompt_version, model, temperature, hashed input)`，因此重新推送不会重复计费。 - 每个 PR 的令牌预算，耗尽时优雅降级。 - Pydantic 验证的结构化输出合约。 - `json_repair` 回退机制，可恢复几乎有效的模型输出（缺少键引号、接近 `max_tokens` 的未终止字符串、缺少逗号），而无需额外消耗一次 LLM 调用。 补丁还获得专用链（优先使用 DeepSeek）、在应用前拒绝乱码的健全性检查，以及确认补丁针对特定漏洞并匹配周围代码风格的第二意见 LLM 审查。 ## 状态 - 5 个并行扫描器（Gitleaks、Semgrep、Grype、Checkov、AI 漏洞发现） - 4 个 LLM 推理代理（AI 发现、可利用性、STRIDE 威胁模型差异、补丁生成 + 审查） - 4 链路提供商故障转移链（DeepSeek、Gemini、Groq、OpenRouter），带 JSON 修复回退和宽容模式 - 3 种策略配置文件（`advisory` / `balanced` / `strict`）和依赖项分流（`direct_runtime` / `direct_dev` / `transitive`），用于校准 CI 门禁 - 可配置的 `scanners.grype.include_transitive` 开关，审查者可选择 SBOM 风格的全量报告（默认）或仅 PR 范围的输出 - 248 个单元测试，ruff 检查通过 - 在标准 Ubuntu CI 运行器上通过 40 个标记测试样本在 2 种管道模式下验证（共 80 次编排器运行），零降级阶段 ### 自我审查证据 智能审查管道已两次在此仓库自身的代码中发现路径遍历漏洞 —— 一次是在引入受影响文件的 PR 上，另一次是在实时交付代码库自我扫描时。两个修复均由机器人自身的威胁建模代理签署确认。 #### 第一轮 —— 机器人在引入 PR 上发现 `manifest_parser` 中的路径遍历 依赖项分流功能在合并前由 SecureFlow AI 自身审查。将实时机器人指向引入新 `manifest_parser` 工具的 PR，STRIDE 威胁建模差异代理标记了一个真实存在的路径遍历弱点 *人类审查者遗漏的*： 原始代码以朴素方式解析所有路径： ``` full = (repo / rel).resolve() if not full.exists() or not full.is_file(): continue sub = _dispatch(full) ``` 交付的修复应用了机器人建议的确切缓解措施 —— `Path.relative_to(repo)`： ``` repo = Path(repo_path).resolve() for rel in manifest_paths: full = (repo / rel).resolve() try: full.relative_to(repo) except ValueError: # Resolved path escapes the repository root — skip. continue # ... + 2 MiB per-manifest size cap as DoS guard ``` 两个单元测试（`test_parse_rejects_path_traversal`、`test_parse_skips_oversized_manifest`）锁定了修复。机器人还标记了缺失的文件大小上限（DoS）—— 同一补丁也解决了该问题。 #### 第二轮 —— 机器人自我食用并在另外两个位置发现了相同模式 第一轮交付后，通过 `secureflow scan --repo .` 将实时管道指向此仓库自身的源代码（参见 [`.github/workflows/dogfood.yml`](.github/workflows/dogfood.yml)），看看会发现什么。威胁建模代理在第一轮未覆盖的两个函数中标记了 **相同的路径遍历模式**： 两个函数现在与第一轮的加固方案一致 —— `Path.relative_to(repo)` 检查 + 每个文件预算 4 倍的硬大小上限。修复 PR 由机器人自身审查，确认两项缓解措施均为 **置信度 1.00**： [`tests/unit/test_agent_file_reader_security.py`](tests/unit/test_agent_file_reader_security.py) 中的六个单元测试锁定了修复。端到端来看，这是智能审查方法能捕获纯扫描工具遗漏的设计级弱点的最有力证据：同一漏洞类别在两轮中于三个不同文件中被发现，第二轮的修复 PR 由机器人以置信度 1.00 签署确认，且 dogfood 工作流保持可用状态以便未来的审查轮次自动运行。 完整组件目录和每个子系统规格参见 [`ARCHITECTURE.md`](ARCHITECTURE.md) 和 [`design/`](design/)。 ## 安装说明 ### 前置条件 - Python 3.11 - `$PATH` 上有 `gitleaks` 和 `grype` 二进制文件 - `semgrep` 和 `checkov` Python 包（通过以下 pip 安装） ### 从源码安装 ``` git clone https://github.com//secureflow-ai.git
cd secureflow-ai
python -m venv .venv
source .venv/bin/activate # PowerShell: .\.venv\Scripts\Activate.ps1
pip install -e . semgrep checkov
```
安装扫描器二进制文件：
```
# Linux / macOS
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh \
| sudo sh -s -- -b /usr/local/bin
GITLEAKS_VERSION=8.30.1
curl -sSL "https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz" \
| tar xz -C /tmp gitleaks
sudo install -m 0755 /tmp/gitleaks /usr/local/bin/gitleaks
```
在 Windows 上：从各工具的发布页面下载预构建二进制文件并将其放在 `PATH` 上。
### API 密钥
将 `.env.example` 复制为 `.env` 并至少填入一个提供商：
```
GROQ_API_KEY= # free tier: https://console.groq.com/keys
GEMINI_API_KEY= # free tier: https://aistudio.google.com/apikey
DEEPSEEK_API_KEY= # paid prepaid: https://platform.deepseek.com/
OPENROUTER_AI_API_KEY= # free tier: https://openrouter.ai/settings/keys
```
当密钥缺失时管道会优雅降级：需要 LLM 的代理在 PR 评论中输出单个跳过横幅，确定性策略决策仍然生效。
## 快速开始
### 本地 CLI
```
# 扫描当前目录
secureflow scan --repo . --output report.json --markdown report.md --sarif report.sarif
# 无需 LLM 调用的快速迭代
secureflow scan --repo . --no-llm
```
CLI 输出 JSON、Markdown 和 SARIF 工件。退出码：`PASS` 或 `WARN` 为 `0`，`FAIL` 为 `1`，终端错误为 `2`。
### 运行评估工具
```
# 确定性基线（无 LLM 成本）
secureflow eval run --no-llm --output reports/eval_scanners_only.md
# 完整 pipeline
secureflow eval run --output reports/eval_full.md \
--llm-concurrency 1 --max-findings-to-exploit 15 --max-patches 5
```
## GitHub Actions 集成
即插即用工作流位于 [`.github/workflows/secureflow.yml`](.github/workflows/secureflow.yml)。将其复制到仓库的 `.github/workflows/` 目录中，然后：
1. 至少添加一个提供商 API 密钥作为仓库密钥。`GROQ_API_KEY` 是最简单的免费选项；`DEEPSEEK_API_KEY` 推荐用于补丁生成。
2. 可选添加 `GEMINI_API_KEY` 和 `OPENROUTER_AI_API_KEY` 用于链故障转移。
3. 打开一个 pull request。
工作流功能：
- 缓存 `.secureflow_cache/`，以 head SHA 为键，以便重新推送时重用 LLM 响应。
- 使用并发组，在快速重新推送时取消过时的运行。
- 在标记 `` 下发布结构化 PR 评论，并在后续推送时编辑同一评论而非创建新评论。
- 启用代码扫描时将 SARIF 上传到仓库的安全选项卡（公共仓库免费；私有仓库需要 GitHub Advanced Security）。
- 在 `FAIL` 决策时以退出码 1 退出，以便 PR 的 CI 状态反映结果。
独立工作流 [`.github/workflows/eval.yml`](.github/workflows/eval.yml) 在触及测试样本或管道代码的 PR 上运行评估工具，并将完整报告作为工件上传。
### 最小权限原则
交付的工作流仅请求：
```
permissions:
contents: read
pull-requests: write
issues: write
security-events: write
actions: read
```
`security-events: write` 仅在启用 SARIF 上传时需要。`issues: write` 是必需的，因为 PR 评论更新路径通过 issues API 处理非审查线程评论。`actions: read` 让 `codeql-action/upload-sarif` 步骤获取工作流运行元数据，而不会出现 "Resource not accessible by integration" 警告。工作流不需要对仓库内容的写访问权限。
## 配置
所有配置位于仓库根目录的 `.secureflow.yml`。每个部分都是可选的，具有合理的默认值。
```
llm:
# Cross-provider chain, strongest first.
provider: deepseek
model: deepseek-chat
fallback_providers: [gemini, groq, openrouter]
# Patch generation has its own chain because patches require higher
# JSON-output reliability than the other schemas.
patch_provider: deepseek
patch_fallback_providers: [gemini, groq]
temperature: 0.1
max_tokens: 4096
cache: true
scanners:
semgrep: { enabled: true, config: auto }
gitleaks: { enabled: true }
grype: { enabled: true }
checkov: { enabled: true } # IaC / Dockerfile / Kubernetes / GH Actions
ai_discovery:
enabled: true
trigger_on_sensitive_files: true
policy:
# advisory | balanced | strict — see "Policy profiles" below.
profile: balanced
fail_on:
- critical_secret
- critical_cve
- high_confidence_injection
- confirmed_auth_bypass
warn_on:
- medium_ai_discovery
- low_confidence_high_impact
- outdated_dependency
minimum_fail_confidence: 0.80
minimum_warn_confidence: 0.50
limits:
max_findings_to_exploit_check: 30
max_patches_per_pr: 10
max_llm_concurrency: 1
```
替代配置（仅本地 Ollama、仅 Gemini、Ollama 补丁）位于 [`examples/configs/`](examples/configs/)。
## 策略配置文件
`policy.profile` 控制发现结果转换为 CI `FAIL` 的严格程度。提供三种配置文件；`balanced` 为默认值。
| 配置文件 | 使用场景 | 行为 |
|---|---|---|
| `advisory` | 初始推出、影子模式运行、团队希望在执行前获得可见性的仓库 | 永不阻止 CI。每个本应 `FAIL` 的发现结果报告为 `WARN` 并带有标记行，以便审查者仍能看到什么 *本应* 被阻止。 |
| `balanced` *（默认）* | 大多数仓库的日常使用 | 阻止关键密钥、直接/传递依赖中的关键 CVE、高置信度注入模式，以及置信度 ≥ 0.85 的 AI 发现关键结果。仅开发依赖中的关键 CVE（eslint、pytest 等）降级为 `WARN`。 |
| `strict* | 安全敏感仓库，其中漏报成本高于误报 | 新增三个阻止项：置信度 ≥ 0.85 的 AI 发现高结果、置信度 ≥ 0.75 的 AI 关键结果（从 0.85 降低）、置信度 ≥ 0.70 的威胁模型 FAIL 建议（从 0.80 降低），以及有可用修复的高严重性直接依赖。 |
```
policy:
profile: strict
```
## 依赖项分流
依赖项发现结果按范围分类以减少噪音：
| 范围 | 来源 | 策略影响（balanced） |
|---|---|---|
| `direct_runtime` | 在 `dependencies` / `[project.dependencies]` / `[packages]` / 运行时 `requirements.txt` 中声明的包 | 完全严格 —— 关键 FAIL，高 WARN |
| `direct_dev` | 在 `devDependencies` / `[tool.poetry.group.dev.dependencies]` / `[dev-packages]` / `requirements-dev.txt` 中声明的包 | 关键降级为 `WARN`（构建专用依赖不随应用程序交付） |
| `transitive` | 在变更清单的任何直接依赖部分中未声明的包 | 与直接运行时相同的 FAIL 条 —— 可达性未知，安全默认值 |
| `unknown` | PR diff 中没有清单，或解析器无法读取 | 保留预分流行为（无回归） |
支持的清单：`package.json`、`pyproject.toml`（PEP 621 + Poetry）、`Pipfile`、`requirements*.txt`。
### 传递发现结果开关
Grype 报告整个已解析依赖树中的 CVE（Flask 1.0.0 引入旧的 Werkzeug + Jinja2 + itsdangerous + click；所有 CVE 都会浮出水面）。默认行为保留此 SBOM 风格报告。设置 `scanners.grype.include_transitive: false` 以丢弃标记为 `transitive` 的发现结果，仅保留 `direct_runtime` / `direct_dev`，以便在触及包清单的 PR 上获得更清晰的机器人评论。
```
scanners:
grype:
enabled: true
include_transitive: false # drop transitive CVEs; default is true
```
标记为 `unknown` 的发现结果（清单解析器尚未覆盖的生态系统 —— Go `go.mod`、Rust `Cargo.toml`、Java `pom.xml`/Gradle、Ruby `Gemfile`、PHP `composer.json`、.NET `*.csproj`、Docker 镜像依赖）**永远不会** 被开关丢弃。Markdown 报告内联渲染 `(unknown)`，以便这些生态系统上的审查者看到开关对其 PR 没有影响的原因。
## 评估
仓库附带 40 个标记测试样本，位于 [`tests/fixtures/`](tests/fixtures/)：
| 类别 | 数量 | 覆盖范围 |
|---|---|---|
| 基础 AppSec | 20 | SQLi、命令注入、SSRF、XSS、XXE、路径遍历、弱加密、JWT `alg:none`、不安全反序列化、IAM 通配符、支付逻辑缺陷、私钥、SHA1 密码、SSL `verify=False`、缺失授权、硬编码密钥、开放重定向、弱 YAML、易受攻击的依赖 |
| 跨语言 | 6 | Go、Java、Ruby、PHP、C#、TypeScript |
| 对抗性提示注入 | 4 | 评论覆盖、虚假审查、角色注入、权限声明 |
| 静态 IaC | 5 | 公共 S3（Terraform）、通配符 IAM、Dockerfile root、开放安全组、过度授权的 GitHub Actions |
| STRIDE 威胁模型 | 2 | 新管理员路由、新文件上传 |
| 真阴性 | 3 | 仅文档、安全的 Python 变更、安全的 subprocess 使用 |
### 汇总结果（40 个测试样本 × 2 种管道模式，在 Ubuntu CI 上）
*捕获于 2026-05-18，状态为组合 W1 + W5 + W15 + W19（开关）+ W22（匹配器）+ 第二轮加固。逐场景细分参见 [`reports/eval_full.md`](reports/eval_full.md)，可复现性辅助文件参见 [`reports/eval_versions.yaml`](reports/eval_versions.yaml)。*
| 指标 | `scanners_only` | `secureflow_full` | Δ |
|---|---|---|---|
| 召回率 | 0.61 | **0.78** | **+0.17** |
| 精确率 | **0.54** | **0.36** | −0.18 |
| **决策正确** | 27 / 40 (67.5%) | **31 / 40 (77.5%)** | **+4** |
| 真阳性 | 28 | 36 | +8 |
| 假阳性 | **24** | **65** | +41 |
| **次要发现（非 FP）** | **41** | **41** | +0 |
| 每场景平均延迟 | 5.9 秒 | 19.8 秒 | +13.9 秒 |
| LLM 令牌（输入 / 输出） | 0 / 0 | 388,885 / 52,737 | — |
| 生成补丁 / 扫描器验证 | 0 / 0 | 40 / 10 | +10 |
**次要发现** 是标记包上的额外 CVE（Django 2.2.0 有 15 个已发布 CVE，但标签期望一个匹配）或标记 IaC 资源上的额外 Checkov 子检查。W22 匹配器修复将这些记为 `secondary` 而非 `FP`，因为系统正确检测到了标记的漏洞，额外发现代表相同的底层问题。W22 之前这些夸大了 FP 计数：当匹配器开始正确记分时，全模式从 **107 FP → 65 FP** 下降。
精确率同样大幅上升（仅扫描器：0.30 → 0.54）—— 原因相同 —— 系统一直在发现这些 CVE；评估只是没有诚实地记分。
### 同一 CI 运行上的管道健康状况 |
| 统计 | 值 |
|---|---|
| 编排器运行完成 | 80 / 80 |
| 模式验证警告 | 0 |
| 需要 `json_repair` 恢复 | 0 |
| 触发链故障转移 | 0 |
| 触发跳过横幅 | 0 |
完整逐场景细分在 [`reports/eval_full.md`](reports/eval_full.md)；原始数据在 [`reports/eval_full.json`](reports/eval_full.json)；扫描器和提供商版本在 [`reports/eval_versions.yaml`](reports/eval_versions.yaml)。
### LLM 半部分改变决策的场景
九个确定性管道给出错误决策而全管道给出正确决策的场景：
| 场景 | `scanners_only` | `secureflow_full` |
|---|---|---|
| `scenario_02_missing_authz` | PASS（错误） | FAIL（AI 发现找到 IDOR） |
| `scenario_08_path_traversal` | PASS（错误） | FAIL（AI 发现揭示了遍历） |
| `scenario_14_business_logic_payment` | PASS（错误） | WARN（语义逻辑缺陷；无 SAST 模式） |
| `scenario_16_jwt_alg_none` | WARN（错误） | FAIL（可利用性代理升级） |
| `scenario_17_private_key` | WARN（错误） | FAIL（LLM 升级严重性） |
| `scenario_20_xxe` | PASS（错误） | FAIL（AI 发现捕获了它） |
| `scenario_js_sqli` | WARN（错误） | FAIL（LLM 升级为 FAIL） |
| `scenario_tm_new_admin_route` | PASS（错误） | FAIL（STRIDE 威胁模型差异） |
| `scenario_iac_gha_overprivileged` | PASS（错误） | WARN（STRIDE 标记了 `pull_request_target` + `permissions: write-all`） |
### 真阴性验证
所有三个干净变更场景在两种模式下均正确产生 PASS：
| 场景 | `scanners_only` | `secureflow_full` |
|---|---|---|
| `scenario_09_safe_subprocess_fp` | PASS | PASS |
| `scenario_docs_only` | PASS | PASS |
| `scenario_safe_python_change` | PASS | PASS |
LLM 半部分不会在干净代码上虚构漏洞。
### 提示注入鲁棒性
所有四个 `scenario_pi_*` 测试样本（评论覆盖、虚假审查、角色注入、权限声明）在两种模式下均正确产生 FAIL。系统提示将仓库内容视为不可信数据，不遵循嵌入的指令。
## 安全模型
- **PR 代码是不可信的。** 每个系统提示都指示 LLM 将代码、注释和字符串字面量视为数据而非指令。
- **API 密钥仅从环境变量读取。** 它们永远不会持久化到磁盘或配置文件。环境边界的防御性 BOM 剥离可防止带有 UTF-8 BOM 的密钥使 `urllib` 的 latin-1 头编码器崩溃。
- **扫描输出中的密钥被掩码。** 掩码器对每条日志记录和报告正文运行。报告显示 `AKIA****` 而非完整凭证。
- **补丁永远不会自动应用。** 生成的补丁以 GitHub 建议块形式呈现；人类审查者应用它们。
- **GitHub Action 请求最小权限**（`contents: read`、`pull-requests: write`、`security-events: write`）。
- **IaC 审查仅为静态。** 不需要实时 AWS、Azure 或 GCP 凭证；Checkov 针对已提交文件运行。
## 局限性
- **多文件数据流分析是启发式的。** 仅基于路径的可达性和 AST 信号；没有完整的调用图或别名分析。捕获常见的单文件污点模式；遗漏跨多个文件的漏洞。
- **补丁验证有两个层级。** 扫描器检测到的发现结果的补丁在修补树上获得完整的扫描器重新运行 —— 如果重新运行不再报告原始发现，则补丁标记为 `verified`。AI 发现的发现结果的补丁没有可重新运行的扫描器规则，因此它们仅通过 LLM 审查路径，并根据第二意见裁决标记为 `verified` 或 `unverified`。两个层级都向审查者展示裁决 + 关注点；没有自动应用。当前运行的验证计数在上方汇总表中。
- **免费层 LLM 配额紧张。** Groq 上限约为 30 RPM 和 6K TPM。Gemini 上限为 200 RPD。DeepSeek 是付费的（每 PR 约 $0.05，含 10 个补丁）。
- **Grype 报告传递依赖 CVE。** Grype 扫描整个已解析的依赖树，而不仅仅是 diff。在提升一个直接依赖的 PR中，这可能会暴露该依赖的传递子项中审查者未直接选择的 CVE。记录为使用 Grype 而非仅清单差异工具的已知成本。
- **本地 Ollama 通过配置支持，但在交付的 CI 工作流中未实际使用。** 当守护进程在本地 CLI 上运行时有效；CI 运行器默认不配置 Ollama。
## 配置选择（非局限性）
- **NVD 丰富化是可选的。** OSV 加上本地 CVSS v3 计算器无需 API 密钥即可覆盖大多数用例。在 `.secureflow.yml` 中启用 NVD 并设置 `NVD_API_KEY` 以获得更高的速率限制层级。
## 文档
| 文档 | 用途 |
|---|---|
| [`ARCHITECTURE.md`](ARCHITECTURE.md) | 组件目录、状态机、横切关注点。 |
| [`design/`](design/) | 每个子系统规格（LLM 栈、编排器、补丁验证、评估工具、模式、敏感文件检测）。 |
| [`CONTRIBUTING.md`](CONTRIBUTING.md) | 如何添加新代理、扫描器或测试样本。 |
| [`examples/`](examples/) | 替代配置和易受攻击的 Terraform 演示。 |
| [`reports/`](reports/) | 最新评估结果和可复现性辅助文件。 |
## 许可证
AGPL-3.0。参见 [`LICENSE`](LICENSE)。
diff + sensitive-file detection] CTX --> SEC[secrets_scan
Gitleaks] CTX --> SAST[sast_scan
Semgrep] CTX --> DEP[dependency_scan
Grype] CTX --> IAC[iac_scan
Checkov] CTX --> AID[ai_discovery
LLM] SEC & SAST & DEP & IAC & AID --> NORM[normalize
dedup + scope filter] NORM --> THM[threat_mapping
CWE / OWASP / ATT&CK] THM --> ENR[enrichment
OSV / CVSS] ENR --> REACH[reachability filter] REACH --> EXP[exploitability
LLM second-opinion] EXP --> PATCH[patch_generation
LLM + git apply + scanner rescan + LLM review] EXP --> TM[threat_model
STRIDE delta LLM] PATCH & TM --> DEC[policy engine
PASS / WARN / FAIL] DEC --> OUT([JSON · Markdown · SARIF · PR comment]) classDef llm fill:#fef3c7,stroke:#d97706 class AID,EXP,PATCH,TM llm ``` 使用 LLM 的节点已着色标注。每次 LLM 调用都经过以下环节： - 跨提供商故障转移链，以便在遇到速率限制、模式验证失败和配额耗尽时自动路由到下一个提供商。 - 基于内容寻址的缓存，键值为 `(prompt_version, model, temperature, hashed input)`，因此重新推送不会重复计费。 - 每个 PR 的令牌预算，耗尽时优雅降级。 - Pydantic 验证的结构化输出合约。 - `json_repair` 回退机制，可恢复几乎有效的模型输出（缺少键引号、接近 `max_tokens` 的未终止字符串、缺少逗号），而无需额外消耗一次 LLM 调用。 补丁还获得专用链（优先使用 DeepSeek）、在应用前拒绝乱码的健全性检查，以及确认补丁针对特定漏洞并匹配周围代码风格的第二意见 LLM 审查。 ## 状态 - 5 个并行扫描器（Gitleaks、Semgrep、Grype、Checkov、AI 漏洞发现） - 4 个 LLM 推理代理（AI 发现、可利用性、STRIDE 威胁模型差异、补丁生成 + 审查） - 4 链路提供商故障转移链（DeepSeek、Gemini、Groq、OpenRouter），带 JSON 修复回退和宽容模式 - 3 种策略配置文件（`advisory` / `balanced` / `strict`）和依赖项分流（`direct_runtime` / `direct_dev` / `transitive`），用于校准 CI 门禁 - 可配置的 `scanners.grype.include_transitive` 开关，审查者可选择 SBOM 风格的全量报告（默认）或仅 PR 范围的输出 - 248 个单元测试，ruff 检查通过 - 在标准 Ubuntu CI 运行器上通过 40 个标记测试样本在 2 种管道模式下验证（共 80 次编排器运行），零降级阶段 ### 自我审查证据 智能审查管道已两次在此仓库自身的代码中发现路径遍历漏洞 —— 一次是在引入受影响文件的 PR 上，另一次是在实时交付代码库自我扫描时。两个修复均由机器人自身的威胁建模代理签署确认。 #### 第一轮 —— 机器人在引入 PR 上发现 `manifest_parser` 中的路径遍历 依赖项分流功能在合并前由 SecureFlow AI 自身审查。将实时机器人指向引入新 `manifest_parser` 工具的 PR，STRIDE 威胁建模差异代理标记了一个真实存在的路径遍历弱点 *人类审查者遗漏的*： 原始代码以朴素方式解析所有路径： ``` full = (repo / rel).resolve() if not full.exists() or not full.is_file(): continue sub = _dispatch(full) ``` 交付的修复应用了机器人建议的确切缓解措施 —— `Path.relative_to(repo)`： ``` repo = Path(repo_path).resolve() for rel in manifest_paths: full = (repo / rel).resolve() try: full.relative_to(repo) except ValueError: # Resolved path escapes the repository root — skip. continue # ... + 2 MiB per-manifest size cap as DoS guard ``` 两个单元测试（`test_parse_rejects_path_traversal`、`test_parse_skips_oversized_manifest`）锁定了修复。机器人还标记了缺失的文件大小上限（DoS）—— 同一补丁也解决了该问题。 #### 第二轮 —— 机器人自我食用并在另外两个位置发现了相同模式 第一轮交付后，通过 `secureflow scan --repo .` 将实时管道指向此仓库自身的源代码（参见 [`.github/workflows/dogfood.yml`](.github/workflows/dogfood.yml)），看看会发现什么。威胁建模代理在第一轮未覆盖的两个函数中标记了 **相同的路径遍历模式**： 两个函数现在与第一轮的加固方案一致 —— `Path.relative_to(repo)` 检查 + 每个文件预算 4 倍的硬大小上限。修复 PR 由机器人自身审查，确认两项缓解措施均为 **置信度 1.00**： [`tests/unit/test_agent_file_reader_security.py`](tests/unit/test_agent_file_reader_security.py) 中的六个单元测试锁定了修复。端到端来看，这是智能审查方法能捕获纯扫描工具遗漏的设计级弱点的最有力证据：同一漏洞类别在两轮中于三个不同文件中被发现，第二轮的修复 PR 由机器人以置信度 1.00 签署确认，且 dogfood 工作流保持可用状态以便未来的审查轮次自动运行。 完整组件目录和每个子系统规格参见 [`ARCHITECTURE.md`](ARCHITECTURE.md) 和 [`design/`](design/)。 ## 安装说明 ### 前置条件 - Python 3.11 - `$PATH` 上有 `gitleaks` 和 `grype` 二进制文件 - `semgrep` 和 `checkov` Python 包（通过以下 pip 安装） ### 从源码安装 ``` git clone https://github.com/
标签：Agentic AI, Angular, C2, CI门控决策, CVSS评分, DevSecOps, Gitleaks, Grype, IaC误配置检测, IP 地址批量处理, LLM推理, OSV, PR审查, Pull Request分析, Pydantic验证, SARIF报告, Semgrep, Sysdig, Vercel, WordPress安全扫描, 上下文感知, 上游代理, 业务逻辑缺陷, 代码审查自动化, 令牌预算, 依赖项CVE, 内容寻址缓存, 可利用性分析, 可达性分析, 多提供者故障转移, 威胁建模STRIDE, 安全扫描, 授权差距, 搜索语句（dork）, 文档安全, 时序注入, 漏洞优先级, 秘密检测, 补丁生成, 设计级威胁, 逆向工具, 静态应用安全测试SAST