indukuk/Claude-Security-agent
GitHub: indukuk/Claude-Security-agent
面向 Python/AWS 与 AI 应用的混合安全扫描器，通过 Z3 形式化 IAM 证明、零信任爆炸半径分析、LLM 零日发现及对抗性辩论验证机制来精准检测并修复深层安全漏洞。
Stars: 0 | Forks: 0
# Claude Security Agent
[](LICENSE)
[](https://www.python.org/)
[](https://semgrep.dev/)
[](https://github.com/Z3Prover/z3)
[](https://www.anthropic.com/)
一款专为 Python/AWS 应用设计的**混合安全扫描器**，它结合了单一工具所不具备的四大能力：Zelkova 风格的 IAM 形式化验证、零信任爆炸半径分析、由 LLM 驱动的零日漏洞发现，以及对抗性的 Prosecutor/Defender/Judge（原告/辩护/法官）验证机制。每一项确认的漏洞发现都会自动生成相应的漏洞利用 PoC 和 pytest 回归测试。
## 它实现了哪些其他工具做不到的功能
### 1 — Zelkova 风格的 Z3 形式化 IAM 验证
借鉴 AWS 内部的 Zelkova 引擎，该扫描器将 IAM 策略编码为 Z3 SMT 约束，并通过形式化**证明**（而非启发式标记）来验证以下三个属性：
**缺失 DynamoDB LeadingKeys（多租户隔离）**
```
SAT( allow_constraint AND leading_key ≠ 'TENANT#expected_*' )
```
如果求解器返回 SAT，则跨租户数据访问即可被形式化证明（而不仅仅是被怀疑）。该证明包含满足条件的赋值（即绕过租户范围限定的确切 partition key 值）。
**通配符操作范围限定**
```
SAT( wildcard_action_matches AND conditions_hold AND action ∈ dangerous_set )
```
通过寻找条件未能排除的危险操作（如 Delete、Create、Admin），证明即使在存在条件限制的情况下，授予 `dynamodb:*` 或 `s3:*` 权限依然是危险的。
**Deny 语句有效性（Zelkova 公式）**
```
SAT( allowed AND NOT denied )
```
证明某条 Deny 语句是否真正缓解了宽泛的 Allow 语句，或者由于 Deny 的作用范围比 Allow 更窄，主体是否仍然能够执行危险操作。
### 2 — 零信任爆炸半径分析
对于每一个 IAM 角色（Lambda 函数），分析器都会**假设其已被攻破**，并精确计算出攻击者能获取哪些权限：
- **爆炸半径得分**：通过 IAM 和网络可达性可访问的基础设施总量的比例
- **遏制分类**：`CONTAINED` / `PARTIALLY_CONTAINED` / `UNCONTAINED`
- **危险能力标志**：`can_access_all_tenants`、`can_exfiltrate_data`、`can_modify_data`、`can_escalate_privileges`
- **Z3 遏制证明**：从形式上证明基于该角色的权限，跨租户资源访问是否成立
- **横向移动图**：三种攻击路径 —— `assume_role` 链、共享数据存储中毒（写入角色 → 共享 DynamoDB → 读取角色），以及直接的 `lambda:InvokeFunction` 提权
每一项确认的应用层漏洞发现都会与爆炸半径映射图进行交叉比对。如果在处于 `UNCONTAINED` 状态、面向互联网且无身份验证的 Lambda 中发现一个 MEDIUM 级别的注入漏洞，该漏洞将被自动提升为 CRITICAL。
### 3 — LLM 零日漏洞发现（Track B — Claude Opus）
Track B 专门搜寻那些尚未存在于任何 CVE 数据库中的漏洞类别。包含四个分析阶段：
**阶段 1 — 异常检测**：针对每个代码类别（auth、数据访问、AI 集成），描绘出*大多数*代码的运行模式，并找出其中的异类。那些在错误处理方式上与众不同、信任假设不同，或者未执行相邻代码所遵循的防护措施的代码，往往是安全漏洞的聚集地。
**阶段 2 — AI/LLM 特有的攻击向量**（新颖 —— 现有的扫描器均未覆盖此类向量）：
- **Memory poisoning**：`memory_id` 是否按租户进行了范围限定？用户 A 能否污染用户 B 的 AI 上下文？
- **通过存储数据进行的 Prompt injection**：评估输出、用户笔记或合规数据是否会被重新注入到未来的 LLM prompt 中？是否存在 存储中→被检索→被注入 的多跳攻击链？
- **Agent 路由操纵**：对抗性输入是否会迫使 AI 路由到非预期的代码路径？
- **工具调用提权**：用户的消息是否会导致 AI agent 调用超出预期权限的工具？
- **跨租户上下文泄露**：日志、embedding 或共享状态是否跨越了信任边界发生泄露？
**阶段 3 — 假设质疑**：针对每个架构元素提出：*这段代码做了什么假设？在什么条件下该假设会失效？攻击者能否让其失效？*
**阶段 4 — 跨服务交互漏洞**：仅由服务间的交互方式引发的漏洞 —— 例如应用程序漏洞 + IAM 过度授权，或者 AI agent + 共享状态 + 未经验证的 endpoint。
### 4 — 对抗性 Prosecutor / Defender / Judge 验证
每一项 HIGH 和 CRITICAL 级别的漏洞发现在被确认之前，都会经历一场三轮 LLM 调用的辩论：
**Prosecutor** 必须证明完整的攻击路径（入口 → 利用 → 影响），且每一项主张都必须以 `[N]` 的形式引用编号的证据包中对应的内容。未经引用的主张将被法官驳回。
**Defender** 负责提出缓解方案或要求降低严重等级 —— 但**严禁虚构代码库中不存在的补偿性控制措施**。如果代码库中确实不存在真正的缓解措施，辩护方必须予以承认。
**Judge** 根据严格的权重标准评估双方：`Z3 证明 > 代码证据 > 基础设施配置 > 推断出的行为`。它会驳回任何未引用证据的论点。最终会作出以下三种裁决之一：
| 裁决 | 含义 |
|---|---|
| `CONFIRMED` | 可按声明的方式进行利用，严重等级维持不变 |
| `CONFIRMED_ADJUSTED` | 可被利用，但严重等级已根据辩护证据进行了调整 |
| `DISMISSED` | 原告未能提供带引用的证据以证明完整的攻击路径 |
零信任交叉比对将并行执行：如果漏洞发现状态为 `CONFIRMED`，且相关资源处于 `UNCONTAINED` 状态并暴露在互联网中，系统将提升其严重等级，并追加横向移动路径。
### 5 — 自动生成漏洞利用 PoC 和回归测试
对于每一项确认的漏洞发现，Layer 4 会生成：
- **漏洞利用 PoC**：演示该漏洞的 curl 命令、Python 脚本或请求序列
- **已验证的修复**：在同一代码库中寻找现有的安全模式，生成补丁，并使用 Semgrep/Z3 重新扫描以确认漏洞已被消除（最多循环 3 次）
- **Pytest 回归测试**：这是一项在漏洞存在时**FAILS**（失败）、在修复应用后**PASSES**（通过）的测试 —— 为防止漏洞再次引入提供永久性屏障
## 流水线概述
```
flowchart LR
REPO["🎯 Target Repo"]
L0["LAYER 0 · Deterministic\nCPG · Semgrep · Z3 IAM\nZero Trust · Chains\n$0 · 26s"]
L1["LAYER 1 · LLM Discovery\nTrack A: Novel patterns\nTrack B: Zero-day (Opus)\nTrack C: 5 domain experts\n$10–15 · 5min"]
L3["LAYER 3 · Validation\nProsecutor → Defender → Judge\nZero Trust cross-ref\n$5–8 · 3min"]
L4["LAYER 4 · Proof\nExploit PoC · Verified fix\nRegression tests\n$3–5 · 2min"]
L5["LAYER 5 · Report\nHTML · Attack chains\nExecutive summary"]
L6["LAYER 6 · Learning 🔄\nFindings → Semgrep rules\nFindings → Z3 specs"]
REPO --> L0 --> L1 --> L3 --> L4 --> L5 --> L6
L6 -. "new rules fed back" .-> L0
style L0 fill:#adf,stroke:#333
style L1 fill:#f9e,stroke:#333
style L3 fill:#ccf,stroke:#333
style L4 fill:#fda,stroke:#333
style L5 fill:#cff,stroke:#333
style L6 fill:#cfc,stroke:#333
```
📐 **[完整架构图 —— 按层级划分的 Mermaid 流程图 →](v6/architecture-diagrams.md)**
## 在多 Agent 编码会话中的角色
在连续的长时间编码会话中，Claude Code 会运行一条由顶层协调器编排的专用 Agent 流水线。安全 Agent 位于代码/测试 Agent 与部署 Agent 之间 —— 它充当一道协调器无法绕过的硬性关卡。
```
┌─────────────────────────────────────────────────────────────────┐
│ ORCHESTRATOR │
│ Coordinates the full session. Passes context between agents. │
│ Cannot proceed to Deploy until Security returns APPROVED. │
└──┬──────────┬──────────┬──────────┬────────┬────────┬──────────┘
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
┌──────┐ ┌────────┐ ┌──────┐ ┌──────────┐ ┌──────┐ ┌───────────┐
│Reqts │ │Research│ │ Plan │ │ Code │ │ Unit │ │ SECURITY │
│Agent │→│ Agent │→│Agent │→│ Agent(s) │→│ Test │→│ AGENT │
│ │ │ │ │ │ │ │ │Agent │ │ (this) │
└──────┘ └────────┘ └──────┘ └──────────┘ └──────┘ └─────┬─────┘
│
┌───────────┴──────────┐
│ │
APPROVED BLOCKED
│ │
▼ ▼
┌──────────┐ Returns findings
│ Deploy │ to Code Agent
│ Agent │ for remediation
└────┬─────┘
│
▼
┌───────────────┐
│ Integration │
│ QA Agent │
└───────────────┘
```
### 各 Agent 交接的内容
| Agent | 产出物 | 传递给 |
|---|---|---|
| Requirements | 验收标准、威胁模型存根 | Research、Plan |
| Research | 现有技术方案、CVE 参考、设计约束 | Plan |
| Plan | 架构决策记录、文件变更计划 | Code Agent(s) |
| Code Agent(s) | 可运行的代码、差异对比、handler 文件 | Unit Test、Security |
| Unit Test | 覆盖率报告、通过的测试套件 | Security |
| **Security Agent** | **APPROVED（通过） / BLOCKED（拦截）+ 漏洞发现 JSON + 回归测试** | **Deploy（如果通过）或 Code Agent（如果被拦截）** |
| Deploy | 已部署的构建产物、环境 URL | Integration QA |
| Integration QA | 端到端测试结果、回归测试套件 | Orchestrator |
### 协调器向安全 Agent 发送的指令
```
# 在 Code + Unit Test agents 完成后：
claude "The code agent has finished implementing the following changes:
- Modified: src/handlers/user_handler.py
- Modified: src/handlers/data_handler.py
- Added: src/services/tenant_service.py
- Infrastructure: infra/stacks/api_stack.py
Run the security scan on /path/to/repo.
Gate rules:
- Any CRITICAL finding → BLOCKED, do not proceed
- Any CONFIRMED HIGH finding → BLOCKED unless finding has approved exception
- MEDIUM findings → APPROVED with findings listed for tracking
- Return: APPROVED or BLOCKED with findings JSON and remediation instructions"
```
### 安全 Agent 返回给协调器的信息
```
{
"verdict": "BLOCKED",
"gate": "dev-deploy",
"summary": {
"critical": 1,
"high": 2,
"medium": 3,
"confirmed_by_debate": 2,
"dismissed_by_debate": 1,
"z3_proven": 1
},
"blocking_findings": [
{
"title": "DynamoDB grant lacks LeadingKeys — cross-tenant access Z3-proven",
"severity": "CRITICAL",
"file": "infra/stacks/api_stack.py:47",
"z3_proof": "SAT(allow AND leading_key ≠ 'TENANT#expected_*')",
"remediation": "Add ForAllValues:StringLike LeadingKeys condition scoped to ${aws:PrincipalTag/tenant_id}",
"regression_test": "tests/security/test_security_multi_tenant_isolation_z3-mul.py"
}
],
"next_action": "Return to Code Agent with blocking_findings. Re-run security scan after remediation."
}
```
### 安全 Agent 回退给代码 Agent 的场景
```
# Orchestrator 指示 Code Agent 进行修复：
claude "Security scan returned BLOCKED. Remediate the following findings before
the next security scan:
1. [CRITICAL] DynamoDB grant lacks LeadingKeys condition (infra/stacks/api_stack.py:47)
Fix: Replace grant_read_write_data() with explicit PolicyStatement including
conditions={'ForAllValues:StringLike': {'dynamodb:LeadingKeys': ['TENANT#...']}}
2. [HIGH] tenant_id read from request body instead of authorizer context (user_handler.py:83)
Fix: Replace event['body']['tenant_id'] with event['requestContext']['authorizer']['claims']['sub']
After remediation, the orchestrator will re-run the security agent before proceeding."
```
### 包含安全反馈机制的完整会话流程
```
Orchestrator
→ Requirements Agent (define what to build + threat model)
→ Research Agent (prior art, security patterns, relevant CVEs)
→ Plan Agent (architecture + security controls in the plan)
→ Code Agent(s) (implement — may spawn parallel agents per module)
→ Unit Test Agent (coverage, passing tests)
→ Security Agent [Gate 1] (Layer 0: deterministic, $0, ~26s)
↳ BLOCKED? → back to Code Agent for remediation → re-run Security Agent
↳ APPROVED? → continue
→ Deploy Agent (deploy to dev)
→ Integration QA Agent (end-to-end tests against dev)
→ Security Agent [Gate 2] (full LLM pipeline before promoting to staging/prod)
↳ BLOCKED? → back to Code Agent
↳ APPROVED? → promote to next environment
```
由 Gate 2 生成的回归测试将被提交回代码仓库，并成为 Unit Test Agent 测试套件的一部分 —— 这样，未来的每一次编码会话都会自动防范再次引入已确认的漏洞。
## 在部署流水线中作为 Claude Code Agent 使用
本扫描器旨在作为 **Claude Code agent** 运行 —— 在部署流水线中由 Claude CLI 调用，而不仅仅是作为独立脚本运行。下方介绍的双关卡模型是推荐的生产环境模式。
```
Code commit
│
▼
┌─────────────────────────────────────────────┐
│ GATE 1 — Dev deploy (every commit) │
│ │
│ claude "run v6/run_v6.py $REPO_PATH │
│ and block deploy if CRITICAL or │
│ HIGH findings exist" │
│ │
│ Layer 0 only · $0 · ~26s │
│ Blocks: unresolved HIGH/CRITICAL findings │
└─────────────────┬───────────────────────────┘
│ findings remediated
▼
Deploy to Dev
│
▼
┌─────────────────────────────────────────────┐
│ GATE 2 — Environment promotion │
│ (dev → staging, staging → prod) │
│ │
│ claude "run v6/run_v6.py $REPO_PATH │
│ --full and produce a security │
│ sign-off report" │
│ │
│ Full pipeline · ~$15–20 · ~15min │
│ Zero-day discovery · Formal proofs │
│ Exploit PoCs · Regression tests │
│ Blocks: any CONFIRMED finding without │
│ approved exception │
└─────────────────┬───────────────────────────┘
│ security sign-off
▼
Promote to next environment
```
### Gate 1 — GitHub Actions（针对 dev 分支的每次提交）
```
# .github/workflows/security-gate-1.yml
name: Security Gate — Dev Deploy
on:
push:
branches: [dev, develop, feature/**]
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install scanner
run: |
pip install semgrep
pip install -e ".[z3]"
- name: Run deterministic scan (Layer 0)
run: python3 v6/run_v6.py ${{ github.workspace }} --layer 0
env:
PYTHONPATH: ${{ github.workspace }}
- name: Block on HIGH/CRITICAL findings
run: |
CRITICAL=$(jq '.severity_distribution.CRITICAL // 0' \
v6/reports/*/summary.json)
HIGH=$(jq '.severity_distribution.HIGH // 0' \
v6/reports/*/summary.json)
if [ "$CRITICAL" -gt 0 ] || [ "$HIGH" -gt 0 ]; then
echo "❌ Security gate failed: $CRITICAL critical, $HIGH high findings"
exit 1
fi
echo "✅ Security gate passed"
- name: Upload report
uses: actions/upload-artifact@v4
with:
name: security-report-layer0
path: v6/reports/
```
### Gate 2 — 环境升级前的全面 LLM 扫描
```
# .github/workflows/security-gate-2.yml
name: Security Gate — Environment Promotion
on:
workflow_dispatch:
inputs:
target_env:
description: 'Target environment (staging or prod)'
required: true
jobs:
full-security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install scanner
run: pip install semgrep && pip install -e ".[z3]"
- name: Run full pipeline (Layer 0 + Claude zero-day investigation)
run: python3 v6/run_v6.py ${{ github.workspace }} --full
env:
AWS_DEFAULT_REGION: us-east-1
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
- name: Require security sign-off
run: |
CONFIRMED=$(jq '[.findings[] | select(.status=="CONFIRMED")] | length' \
v6/reports/*/findings.json)
if [ "$CONFIRMED" -gt 0 ]; then
echo "❌ Promotion blocked: $CONFIRMED confirmed findings require remediation"
exit 1
fi
- name: Upload full report + regression tests
uses: actions/upload-artifact@v4
with:
name: security-report-full-${{ inputs.target_env }}
path: v6/reports/
```
### 直接使用 Claude CLI 运行
```
# Gate 1：确定性检查
claude "run the Layer 0 security scan on /path/to/repo and tell me if it's safe to deploy to dev"
# Gate 2：提升前的全面零日分析
claude "run the full v6 security pipeline on /path/to/repo and produce a sign-off report for promoting to staging"
# 临时：调查特定发现
claude "the scanner found a DynamoDB LeadingKeys violation in user_handler.py — show me the Z3 proof and generate an exploit PoC"
```
### 退出码
| 代码 | 含义 |
|---|---|
| `0` | 安全 —— 无漏洞发现 |
| `1` | 存在 HIGH 级别的漏洞发现 |
| `2` | 存在 CRITICAL 级别的漏洞发现 |
Gate 1 将在退出码为 `1` 或 `2` 时触发拦截。Gate 2 则会在发现任何没有批准例外（位于 `v6/rules/exceptions/` 中）的 `CONFIRMED` 漏洞时触发拦截。
## 快速开始
### 前置条件
```
pip install semgrep
pip install -e .
pip install -e ".[z3]" # Required for IAM proofs and containment analysis
pip install -e ".[tree-sitter]" # Optional: deeper AST parsing
```
LLM 模式需要 AWS Bedrock 凭证。Layer 0 可完全在离线环境下运行。
### 运行 V6（最新版本）
```
# 仅 Layer 0 — 免费，约26秒，无 LLM
python3 v6/run_v6.py /path/to/your/repo
# 完整流水线 — Layer 0 + 会话内 Claude 零日调查
python3 v6/run_v6.py /path/to/your/repo --full
```
报告：`v6/reports//security-report.html`
早期版本的所有功能均已内置于 V6 中。请使用 `v6/run_v6.py` 执行所有操作。
## Layer 0 的发现内容（确定性，$0）
| 类别 | 技术 | 漏洞发现示例 |
|---|---|---|
| 多租户隔离 | Z3 LeadingKeys 证明 | `SAT`：Lambda 角色在没有租户范围 partition key 条件的情况下访问 DynamoDB |
| IAM 过度授权 | Z3 通配符范围限定 | 所有表上的 `dynamodb:*` —— Z3 证明尽管存在条件限制，`DeleteTable` 依然可达 |
| Deny 绕过 | Zelkova 公式 | `SAT(allowed AND NOT denied)` —— Deny 范围窄于 Allow |
| 未受遏制的爆炸半径 | 零信任 + Z3 | 面向互联网的 Lambda，无 VPC，爆炸半径占基础设施的 80%，0 身份验证 |
| 横向移动 | IAM 图遍历 | `role_observer` → 假设身份为 `role_admin` → 获取完整的租户数据访问权 |
| 污点注入 | CPG 证据遍历 | 用户输入 → `tenant_id` 参数 → DynamoDB key（5 步 BFS 追踪） |
| 身份验证绕过 | 差异分析 | 12 个 handler 中有 11 个检查了所有权；1 个未检查 —— 差异分析将其暴露出来 |
| 缺失控制 | 缺失检测 | 违反了强制防护规范：handler 在未记录审计日志的情况下写入用户数据 |
| DOM XSS | Semgrep 污点规则 | 从 `window.location.search` 可到达 `innerHTML` sink |
| 代码中的机密信息 | 模式匹配 | 前端 JS 中存在硬编码的 API key |
## Layer 1 的发现内容（LLM，约 $15/季度）
| Track | 模型 | 目标 |
|---|---|---|
| Track A — 新颖模式 | Sonnet | 声明但未强制执行的控制措施、隐式契约违规（11 个 handler 都执行了某项操作，唯独 1 个跳过了）、敏感数据流向外部服务、TOCTOU 竞争条件 |
| Track B — 零日漏洞 | Opus | AI memory poisoning、通过存储的评估数据进行的 prompt injection、agent 路由操纵、跨租户 embedding 泄露、CVE 结构变体、由 Z3 证明的规范违规 |
| Track C — 领域专家 | Sonnet（×5 并行） | 租户隔离、auth 架构、数据流、爆炸半径、业务逻辑/合规悖论 |
## V6 的构建过程 — 演进历史
V6 是单一的生产级工具。它历经六个版本迭代构建而成，每一版都增加了一项现已原生集成在 V6 中的功能。早期版本保留在代码仓库中，作为其开发过程的研究历史记录。
| 版本 新增功能 —— 现已集成于 V6 |
|---|---|
| V1 | Code Property Graph、Z3 IAM 证明（Zelkova 方法）、Bedrock LLM 集成 |
| V2 | Semgrep 污点规则、Chain-of-Thought 推理流水线 |
| V3 | Generator → Verifier → Prover 模式、对抗性接地辩论（Prosecutor/Defender/Judge） |
| V4 | 过程间证据遍历、缺失检测、差异路径分析、攻击链合成 |
| V5 | 零信任爆炸半径、Z3 遏制证明、领域专家 LLM agent |
| **V6** | **零日漏洞发现、AI/LLM 攻击向量、自我改进的飞轮效应、回归测试生成 —— 完整系统** |
V6 有两种运行模式：
```
# 仅确定性 — Layer 0，$0，约26秒，无需 LLM
# CPG + Semgrep + Z3 IAM 证明 + Zero Trust 爆炸半径 + 攻击链
python3 v6/run_v6.py /path/to/repo
# 完整流水线 — Layer 0 + Claude 零日调查
# 新增：新模式发现、零日搜寻、对抗性辩论、
# exploit PoC、已验证的修复、回归测试
python3 v6/run_v6.py /path/to/repo --full
```
## 成本模型
| 层级 | 运行频率 | 耗时 | 成本 |
|---|---|---|---|
| 0 — 确定性 | 每次提交 (CI/CD) | 26秒 | **$0** |
| 1 — LLM 发现 | 季度 / 重大版本发布 | 5 分钟 | $10–15 |
| 3 — 辩论验证 | 按发现并行处理 | 3 分钟 | $5–8 |
| 4 — 证明 + 回归测试 | 按发现并行处理 | 2 分钟 | $3–5 |
| 5 — 综合 | 每次扫描运行一次 | 2 分钟 | $2–3 |
| 6 — 学习 | 扫描后 | 1 分钟 | $0 |
| **完整流水线** | | **~15 分钟** | **~$15–20** |
**最佳策略：** Track B 使用 Opus（零日漏洞发现需要前沿的推理能力），其他环节均使用 Sonnet。
飞轮效应：每次完整扫描都会将新发现的漏洞模式写回为确定性规则。随着时间的推移，Layer 0 能在无 LLM 成本的情况下捕获更多漏洞。
## 技术栈
- **代码分析**：自定义的过程间 Code Property Graph (networkx)，[Semgrep](https://semgrep.dev/) 包含 5 个自定义规则集、tree-sitter AST（可选）
- **形式化验证**：[Z3 SMT solver](https://github.com/Z3Prover/z3) —— Zelkova 风格的 IAM 编码、遏制证明、规范推断
- **LLM 推理**：通过 AWS Bedrock 调用的 [Claude Sonnet & Opus](https://www.anthropic.com/)
- **基础设施**：AWS CDK / CloudFormation 解析、IAM 图、网络隔离分析
- **扫描语言**：Python、JavaScript、Go、Swift、HCL (Terraform/CDK)
## 贡献
最受欢迎的贡献：
- 新的 Semgrep 规则：`v6/rules/base/`
- 用于变体分析的 CVE 种子：`v6/knowledge/cve_seeds/`
- AI/LLM 攻击模式：`v6/knowledge/ai_attack_patterns/`
- Layer 2、4、5、6 的实现 —— 规范详见 `v6/DESIGN.md`
在进行大型 PR 之前，请先提交一个 Issue。
## 许可证
Apache License 2.0 —— 详见 [LICENSE](LICENSE)。
版权所有 2024–2026 Krishna Indukuri
**Krishna Indukuri** · [GitHub @indukuk](https://github.com/indukuk)
*LLM 增强的形式化分析能否发现纯粹的静态分析和纯粹的 LLM prompt 单独无法找到的漏洞？这就是答案。*
标签：AI安全智能体, AWS安全, Claude, CVE检测, DLL 劫持, IAM权限分析, Z3求解器, 加密, 大语言模型, 安全规则引擎, 漏洞扫描器, 逆向工具