Sentinel-Audits/sentinelaudit-oss
GitHub: Sentinel-Audits/sentinelaudit-oss
面向 EVM 生态的 AI 辅助智能合约安全审计工作流，通过语义提取、严格提升策略和多通道验证实现从静态分析到可提交赏金报告的结构化闭环。
Stars: 0 | Forks: 0
# Sentinel 审计
[](D:/projects/audit/apps/LICENSE)
[](D:/projects/audit/apps/OSS_MODULES.md)
[](D:/projects/audit/apps/OSS_MODULES.md)
SentinelAudit 是一个针对 Ethereum 及更广泛的 EVM 生态系统的 AI 辅助智能合约安全工作流。
本仓库是该项目选择性开源的接口部分：位于产品底层的可复用分类、分析和验证工具集。
## 入门指南
核心公开部分：
- LLM 分类线束
- Slither 运行器辅助模块
- 基准测试语料库和评分卡脚本
- 发布和评估文档
从这里开始：
- [OSS_MODULES.md](D:/projects/audit/apps/OSS_MODULES.md)
- [CONTRIBUTING.md](D:/projects/audit/apps/CONTRIBUTING.md)
- [CODE_OF_CONDUCT.md](D:/projects/audit/apps/CODE_OF_CONDUCT.md)
这不仅仅是“运行 Slither 并总结结果”。该系统旨在：
- 从选定的仓库文件中组装一个可编译的工作区
- 针对该工作区运行静态分析
- 将发现的结果结构化为可生成报告的对象
- 将赏金范围纳入分类、验证和档案生成环节
- 将第一方发现与依赖项风险区分开来
- 将低信号输出保留在研究通道中，而不是全部予以提升
- 支持验证工作流，而不是在扫描器输出阶段就停止
当前的产品方向记录在 [ROADMAP.md](D:/projects/audit/apps/ROADMAP.md) 中。
## 开源范围
本仓库旨在公开可复用的安全工作流构建模块：
- 结构化的分类线束
- 感知仓库的编译和扫描辅助工具
- 公共基准测试语料库和评分卡生成
- 验证运行器模式
- 发布和评估方法
私有产品层（如计费、身份验证、客户历史记录和内部审计智能操作）被故意排除在公开范围之外。
## 公共结构
SentinelAudit 正在为选择性公开发布做准备。
近期计划如下：
- 首先发布可复用的工具和重方法的组件
- 保持计费、身份验证、客户数据路径和内部智能流的私密性
- 在有计划地开放模块的同时，避免破坏现有的产品控制平面
参见：
- [PUBLIC_RELEASE_BOUNDARY.md](D:/projects/audit/apps/docs/PUBLIC_RELEASE_BOUNDARY.md)
- [OSS_MODULES.md](D:/projects/audit/apps/OSS_MODULES.md)
- [PUBLIC_RELEASE_CHECKLIST.md](D:/projects/audit/apps/PUBLIC_RELEASE_CHECKLIST.md)
- [PUBLIC_REPO_SETUP.md](D:/projects/audit/apps/PUBLIC_REPO_SETUP.md)
- [CONTRIBUTING.md](D:/projects/audit/apps/CONTRIBUTING.md)
- [CODE_OF_CONDUCT.md](D:/projects/audit/apps/CODE_OF_CONDUCT.md)
- [SECURITY.md](D:/projects/audit/apps/SECURITY.md)
- [LICENSE](D:/projects/audit/apps/LICENSE)
- [NOTICE](D:/projects/audit/apps/NOTICE)
在发布仓库的任何部分之前，请运行：
```
bun run audit:public-surface
```
## 架构
```
flowchart LR
U["User"] --> W["web
Next.js UI"] W --> B["backend
Cloudflare Worker + Hono"] B --> S["slither runner
compile + scan"] B --> L["llm-worker
structuring + fixes + dossiers"] B --> E["echidna runner
optional fuzzing"] B --> R["R2 + DB
workspace, findings, jobs, events"] S --> B L --> B E --> B B --> W ``` ## 审计模型 ``` flowchart TD A["Selected repo files"] --> B["Repo-aware workspace expansion"] B --> C["Compile context
foundry/remappings/config/vendor roots"] C --> D["Slither detectors"] D --> E["Normalized findings"] E --> F["Semantic fact extraction"] F --> F2["Dimensional fact extraction
selected accounting paths"] F2 --> G["Structured report objects"] G --> H["Promotion policy"] H --> I["Report findings"] H --> J["Needs review"] H --> K["Research notes"] G --> L["Dependency findings lane"] I --> N["Validation lane
fuzz / deterministic / manual PoC"] N --> O["Bounty dossier + export pack"] H --> M["Evaluation harnesses
goldset + repo + auditor review set"] ``` ## 范围界定理念 Sentinel 现在区分以下内容： - 第一方发现：用户项目代码中的问题 - 依赖项发现：打包的或第三方代码，如 `lib/`、`vendor/`、`node_modules/` 和包导入 - 研究笔记：保留用于人工审查的低信号输出 当需要编译和上下文时，仍会对依赖项进行分析，但默认情况下它们不应主导主报告的结论。 ## 信任模型 Sentinel 现在构建于更严格的提升规则之上： - 检测器输出是不够的 - 语义事实优先 - 提升策略决定某项内容应变为： - `report_finding` - `needs_review` - `research_note` Sentinel 尝试自动回答的核心问题是： - 谁可以调用此路径 - 存在什么保护机制 - 谁控制危险参数 - 在外部交互之前状态是否已确定 - 受影响的代码是第一方代码还是依赖项代码 - 算术/记账逻辑是否以可疑的方式混合了资产、份额、价格或费用比例等单元 如果这些答案站不住脚或不完整，Sentinel 应该暂缓该发现，而不是假装拥有比实际情况更高的置信度。 对于对记账敏感的发现，Sentinel 还使用了一个狭义的维度推理层。这并不是对所有检测器的全面通行证；它仅应用于选定的资金路径，在这些路径中，单元混淆可能会实质性地影响可利用性和提升置信度。 ## 服务 典型的本地服务： - `web` 位于 `http://localhost:3000` - `backend` 位于 `http://localhost:8787` - `workers/llm-worker` 位于 `http://localhost:8788` - `api/slither` 位于 `http://localhost:8080` ## 一次性设置 1. 安装依赖： ``` cd web && bun install cd ../backend && bun install cd ../workers/llm-worker && bun install cd ../.. ``` 2. 准备 env 文件： - `web/.env.local` - 设置 `NEXT_PUBLIC_API_URL=http://localhost:8787` - `backend/.dev.vars` - 本地后端 worker 配置 - `workers/llm-worker/.dev.vars` - 从 `workers/llm-worker/.dev.vars.example` 复制 3. 确保 Docker Desktop 正在运行 Slither。 ## 本地运行 从 [D:\projects\audit\apps](D:/projects/audit/apps) 开始： ``` bun run dev:slither bun run dev:echidna bun run dev:llm bun run dev:backend bun run dev:web ``` ## 本地验证 ``` bun run check:local ``` 当前验证内容： - web TypeScript 编译通过 - 后端测试套件通过 - `llm-worker` 本地安全测试通过 ## 重要的本地注意事项 - 本地报告结构化发生在作业达到 `READY` 状态之后，而不是在刷新报告页面时发生 - 本地后端应使用 `LLM_WORKER_URL=http://127.0.0.1:8788` - backend 和 `llm-worker` 必须共享相同的 `LLM_WORKER_TOKEN` - 本地后端将内联发现发送给本地 worker，因为 Wrangler 模拟的本地 R2 不会在服务间共享 - `backend/.dev.vars` 应将 `SLITHER_RUNNER_URL` 指向 `http://localhost:8080` ## AI 负责的内容 AI 被用作确定性输入之上的受约束层。 良好的用途： - 结构化规范化发现 - 面向可利用性的分类 - 修复方案生成 - 赏金档案生成 - Echidna 线束规划/生成 - 为确定性测试和手动 PoC 生成证明计划 - 通过感知仓库的 Foundry/Hardhat 选择来进行确定性测试生成和执行 不良的用途： - 从原始检测器输出中捏造漏洞 - 将依赖项噪声提升为第一方发现 - 表现得像是一键替代人类审计判断的工具 ## 依然最重要的内容 下一个重大的质量飞跃不是“更多的 AI”。 而是自动化的仓库局部语义提取和更强的提升策略： - 谁能调用它 - 什么在保护它 - 哪些输入是攻击者控制的 - 敏感调用前后发生了什么状态变化 - 代码是第一方的还是打包引入的 这才是从“AI 辅助扫描器”迈向“真正审计分类系统”的路径。 ## 验证模型 Sentinel 现在将验证视为发现结果结构化之后的一等通道。 - `fuzz_target` - 适用于 Echidna 线束生成和反例搜索 - `deterministic_test` - 最好通过清晰的交易序列、Foundry 测试和状态断言来验证 - `manual_poc` - 需要攻击者演练、证据捕获和面向审查者的证明 - `review_only` - 有用的上下文，但不值得生成自动化证明 验证证据可以强化发现结果： - 成功的 Echidna 反例会被合并回报告发现中 - 来自 Foundry 或 Hardhat 的成功确定性测试会被合并回报告发现中 - 已验证的发现会在报告排序中上升 - 赏金档案和导出现在明确带有验证状态 ## 赏金工作流 Sentinel 的赏金模式不仅仅是一份主题报告。 它现在支持： - 在 `/bounty` 上进行范围设置 - 从一开始就附加赏金范围的新审计 - 将赏金范围附加到现有的已完成审计 - 在结构化期间进行感知赏金范围的 LLM 分类 - 赏金档案生成 - 赏金包导出 - 针对手动 PoC 和确定性测试工作的证明规划 ## 评估线束 Sentinel 现在在 [workers/llm-worker](D:/projects/audit/apps/workers/llm-worker) 内部有三个互补的信任线束： - 代码片段黄金集 - 孤立案例的结论质量 - 仓库基准测试集 - 仓库形态的回归测试夹具 - 审计员审查集 - 判断某个发现是否足够强大以至于值得放入主报告 有用的命令： ``` cd workers/llm-worker bun run test:triage bun run eval:triage bun run eval:triage:repo bun run eval:triage:auditor ``` ## 生产学习循环 Sentinel 现在拥有了真正的生产学习循环的开端。 对于每次完成的审计，后端会在 R2 中存储一个私有的审计智能工件，路径为： - `results/internal/audit-intelligence/.json`
目标是在不依赖固定目标列表的情况下，使真实的审计运行有助于随时间推移改进 Sentinel。这些工件旨在用于：
- 批量下载和离线分析
- 查找仍然会产生嘈杂的 `needs_review` 输出的检测器家族
- 发现真实仓库中语义事实覆盖率较低的情况
- 从真实使用中构建新的基准测试夹具和审计员审查案例
## 更多文档
- [backend/README.md](D:/projects/audit/apps/backend/README.md)
- [web/README.md](D:/projects/audit/apps/web/README.md)
- [workers/llm-worker/README.md](D:/projects/audit/apps/workers/llm-worker/README.md)
- [ROADMAP.md](D:/projects/audit/apps/ROADMAP.md)
Next.js UI"] W --> B["backend
Cloudflare Worker + Hono"] B --> S["slither runner
compile + scan"] B --> L["llm-worker
structuring + fixes + dossiers"] B --> E["echidna runner
optional fuzzing"] B --> R["R2 + DB
workspace, findings, jobs, events"] S --> B L --> B E --> B B --> W ``` ## 审计模型 ``` flowchart TD A["Selected repo files"] --> B["Repo-aware workspace expansion"] B --> C["Compile context
foundry/remappings/config/vendor roots"] C --> D["Slither detectors"] D --> E["Normalized findings"] E --> F["Semantic fact extraction"] F --> F2["Dimensional fact extraction
selected accounting paths"] F2 --> G["Structured report objects"] G --> H["Promotion policy"] H --> I["Report findings"] H --> J["Needs review"] H --> K["Research notes"] G --> L["Dependency findings lane"] I --> N["Validation lane
fuzz / deterministic / manual PoC"] N --> O["Bounty dossier + export pack"] H --> M["Evaluation harnesses
goldset + repo + auditor review set"] ``` ## 范围界定理念 Sentinel 现在区分以下内容： - 第一方发现：用户项目代码中的问题 - 依赖项发现：打包的或第三方代码，如 `lib/`、`vendor/`、`node_modules/` 和包导入 - 研究笔记：保留用于人工审查的低信号输出 当需要编译和上下文时，仍会对依赖项进行分析，但默认情况下它们不应主导主报告的结论。 ## 信任模型 Sentinel 现在构建于更严格的提升规则之上： - 检测器输出是不够的 - 语义事实优先 - 提升策略决定某项内容应变为： - `report_finding` - `needs_review` - `research_note` Sentinel 尝试自动回答的核心问题是： - 谁可以调用此路径 - 存在什么保护机制 - 谁控制危险参数 - 在外部交互之前状态是否已确定 - 受影响的代码是第一方代码还是依赖项代码 - 算术/记账逻辑是否以可疑的方式混合了资产、份额、价格或费用比例等单元 如果这些答案站不住脚或不完整，Sentinel 应该暂缓该发现，而不是假装拥有比实际情况更高的置信度。 对于对记账敏感的发现，Sentinel 还使用了一个狭义的维度推理层。这并不是对所有检测器的全面通行证；它仅应用于选定的资金路径，在这些路径中，单元混淆可能会实质性地影响可利用性和提升置信度。 ## 服务 典型的本地服务： - `web` 位于 `http://localhost:3000` - `backend` 位于 `http://localhost:8787` - `workers/llm-worker` 位于 `http://localhost:8788` - `api/slither` 位于 `http://localhost:8080` ## 一次性设置 1. 安装依赖： ``` cd web && bun install cd ../backend && bun install cd ../workers/llm-worker && bun install cd ../.. ``` 2. 准备 env 文件： - `web/.env.local` - 设置 `NEXT_PUBLIC_API_URL=http://localhost:8787` - `backend/.dev.vars` - 本地后端 worker 配置 - `workers/llm-worker/.dev.vars` - 从 `workers/llm-worker/.dev.vars.example` 复制 3. 确保 Docker Desktop 正在运行 Slither。 ## 本地运行 从 [D:\projects\audit\apps](D:/projects/audit/apps) 开始： ``` bun run dev:slither bun run dev:echidna bun run dev:llm bun run dev:backend bun run dev:web ``` ## 本地验证 ``` bun run check:local ``` 当前验证内容： - web TypeScript 编译通过 - 后端测试套件通过 - `llm-worker` 本地安全测试通过 ## 重要的本地注意事项 - 本地报告结构化发生在作业达到 `READY` 状态之后，而不是在刷新报告页面时发生 - 本地后端应使用 `LLM_WORKER_URL=http://127.0.0.1:8788` - backend 和 `llm-worker` 必须共享相同的 `LLM_WORKER_TOKEN` - 本地后端将内联发现发送给本地 worker，因为 Wrangler 模拟的本地 R2 不会在服务间共享 - `backend/.dev.vars` 应将 `SLITHER_RUNNER_URL` 指向 `http://localhost:8080` ## AI 负责的内容 AI 被用作确定性输入之上的受约束层。 良好的用途： - 结构化规范化发现 - 面向可利用性的分类 - 修复方案生成 - 赏金档案生成 - Echidna 线束规划/生成 - 为确定性测试和手动 PoC 生成证明计划 - 通过感知仓库的 Foundry/Hardhat 选择来进行确定性测试生成和执行 不良的用途： - 从原始检测器输出中捏造漏洞 - 将依赖项噪声提升为第一方发现 - 表现得像是一键替代人类审计判断的工具 ## 依然最重要的内容 下一个重大的质量飞跃不是“更多的 AI”。 而是自动化的仓库局部语义提取和更强的提升策略： - 谁能调用它 - 什么在保护它 - 哪些输入是攻击者控制的 - 敏感调用前后发生了什么状态变化 - 代码是第一方的还是打包引入的 这才是从“AI 辅助扫描器”迈向“真正审计分类系统”的路径。 ## 验证模型 Sentinel 现在将验证视为发现结果结构化之后的一等通道。 - `fuzz_target` - 适用于 Echidna 线束生成和反例搜索 - `deterministic_test` - 最好通过清晰的交易序列、Foundry 测试和状态断言来验证 - `manual_poc` - 需要攻击者演练、证据捕获和面向审查者的证明 - `review_only` - 有用的上下文，但不值得生成自动化证明 验证证据可以强化发现结果： - 成功的 Echidna 反例会被合并回报告发现中 - 来自 Foundry 或 Hardhat 的成功确定性测试会被合并回报告发现中 - 已验证的发现会在报告排序中上升 - 赏金档案和导出现在明确带有验证状态 ## 赏金工作流 Sentinel 的赏金模式不仅仅是一份主题报告。 它现在支持： - 在 `/bounty` 上进行范围设置 - 从一开始就附加赏金范围的新审计 - 将赏金范围附加到现有的已完成审计 - 在结构化期间进行感知赏金范围的 LLM 分类 - 赏金档案生成 - 赏金包导出 - 针对手动 PoC 和确定性测试工作的证明规划 ## 评估线束 Sentinel 现在在 [workers/llm-worker](D:/projects/audit/apps/workers/llm-worker) 内部有三个互补的信任线束： - 代码片段黄金集 - 孤立案例的结论质量 - 仓库基准测试集 - 仓库形态的回归测试夹具 - 审计员审查集 - 判断某个发现是否足够强大以至于值得放入主报告 有用的命令： ``` cd workers/llm-worker bun run test:triage bun run eval:triage bun run eval:triage:repo bun run eval:triage:auditor ``` ## 生产学习循环 Sentinel 现在拥有了真正的生产学习循环的开端。 对于每次完成的审计，后端会在 R2 中存储一个私有的审计智能工件，路径为： - `results/internal/audit-intelligence/
标签：C2, EVM生态系统, LLM大模型, Slither, Solidity安全, Web3安全, 人工智能辅助, 代码安全审查, 代码审计工具, 以太坊安全, 以太坊开发, 依赖风险分析, 区块链安全, 反取证, 安全工作流, 安全评估, 密码学安全, 开源安全工具, 智能合约安全, 漏洞分类, 漏洞报告生成, 程序员工具, 自动化攻击, 逆向工程平台, 错误基检测, 静态代码分析