asmit25805/code-auditor

# 代码 Auditor 一个自动化的安全和漏洞查找流水线。它会扫描公开的 GitHub 仓库，通过多次 LLM 审查来验证发现的问题，并直接在目标仓库中创建 issue —— 全程无需人工干预。 独立开发。基于免费层级推理运行。没有资金，没有团队。 ## 它能做什么 Code Auditor 会扫描代码库，使用 LLM 生成候选的发现问题，然后在这些发现被作为 GitHub issue 发布之前，通过第二和第三次审查来运行它们。目标不在于数量——而是确保维护者能够充分信任报告，从而直接采取行动，而无需自己去验证。 **流水线：** 1. **扫描** —— 拉取目标仓库，遍历源代码树 2. **首次分析** —— LLM 标记潜在的 bug/漏洞，必须引用确切的代码行 3. **二次验证** —— 独立的 LLM 流程会问“这是真的，还是误报？” 4. **静态验证层** —— 代码检查发现中引用的每个函数/变量/文件路径是否真实存在——自动拒绝产生幻觉的引用 5. **置信度门限** —— 只有置信度高于 0.92 的发现才能通过 6. **上下文检查** —— 在标记任何依赖于上下文的问题之前，流水线会先读取项目类型（例如，“无限制的 stdin”在 Web 服务器中是一个真正的问题，但在 CLI 工具中则不是问题） 7. **模板感知报告** —— 在发布之前，bot 会读取仓库的 `CONTRIBUTING.md`（如果存在），并使报告符合该仓库自己的 bug 报告格式和规范，而不是发布通用的模板 8. **发布** —— 创建一个包含发现、确切代码行引用和严重程度的 GitHub issue 在“LLM 产生想法”和“发布 issue”之间，总共有 12 层验证机制。 ## 为什么需要模板感知步骤 这个 bot 的早期版本完全忽略了仓库规范，无论维护者的期望如何，都发布固定的格式。至少有一位维护者因为报告不符合他们的贡献指南而拒绝了它。修复方法是：在生成报告之前阅读 `CONTRIBUTING.md` 并去适应它，而不是假设一种万能的格式能在任何地方都行得通。 ## 两种报告格式，截然不同的记录 这个项目经历了一次真实的格式转变，诚实面对它的两面性是值得的，而不是仅仅展示好看的数据。 **早期/批量格式** —— 一个 issue 中包含许多发现（每份报告 10-30+ 个）。这就是误报问题所在。多个仓库的维护者将这些报告标记为警报疲劳，要求拆分发现的问题，或者用一个词“tldr（太长不看）”将它们关闭。此格式已被弃用。 **当前/范围格式** —— 每个 issue 仅包含一个发现，并通过上述完整流水线进行端到端验证。在最近的一批范围报告中，这种格式产生了真实的、经维护者确认的修复，并且整个集合中仅有一个已确认的误报——误报率大约为 5%，比批量时代有了巨大的改进。 教训是：报告的颗粒度比验证层更重要。一个自信的 LLM 在一个 issue 中产生 25 个发现，无论底层的分析有多好，它总是被当成垃圾信息。每个 issue 包含一个范围明确、验证充分的发现，才是真正能被阅读和修复的方式。 ## 结果 由维护者修复的已确认真实 bug 包括（非详尽列表）： - **deeplethe/forkd** —— 阻塞式 `accept()` 死锁，当日合并 - **nubjs/nub** —— 通过未经验证的 `bin_subpath` 导致的路径遍历，在 v0.2.4 中修复；缓存键 bug，在同一版本中修复 - **Helvesec/rmux** —— 反序列化器 bug，在 v0.7.1 中解决 - **vercel-labs/zerolang** —— NULL 指针解引用，已确认并修复 - **vercel/eve** —— 未定义的身份验证密钥 + null AbortSignal bug，两者均已修复 - **BigPizzaV3/CodexPlusPlus** —— 通过未经检查的备份路径导致的任意文件写入，已修复并推送到 main 分支 - **nexu-io/html-anything** —— 零持续时间处理 bug 和通过 `document.write` 进行未经清理的 HTML 注入，两者均被确认为真实问题 跨越两种格式时代，在公开仓库中总共修复了 20 多个已验证的 bug。 ## 技术栈 - **语言：** Python - **主要推理：** Cerebras (Llama 3.3 70B，每天 100 万免费 token) - **备用推理：** Groq - **任务调度：** GitHub Actions cron - **状态追踪：** SQLite (追踪已扫描的内容以避免重复报告) - **成本：** 运行成本为 $0 —— 完全基于免费层级 ## 诚实的局限性 - 置信度评分会减少但不能消除误报 - 依赖上下文的发现（看起来像 bug 的有意设计选择）是目前主要的失败模式 - 该流水线审查公开仓库；它没有写入权限，也从不自行发起 PR —— 只创建 issue，供人类维护者采取行动 - 这是一个独立的研究/工具项目，不是商业产品 ## 许可证 该工具本身遵循 CC BY-NC 协议。请查看仓库以获取完整的许可文本。 由 [@asmit25805](https://github.com/asmit25805) 构建和维护。

标签：DLL 劫持, GitHub自动化, Python, 大语言模型, 对称加密, 无后门, 自动化审计, 逆向工具, 错误基检测, 静态代码分析