HN讨论 · 身份未知
AI 生成代码的安全扫描需要专属规则与误报过滤
Sentrint 项目把 AI 生成代码的安全检查作为独立问题：用确定性扫描规则覆盖 RLS、Secrets、Buckets 等 AI 代码特有漏洞模式，再用 AI 层过滤 CRITICAL/HIGH 误报并生成修复。这显示开发者在发布 AI 功能前，需要比通用安全扫描更贴合生成代码的检查方式。
查看原始信号hn:49564974
目标用户
依赖 AI 生成代码、需要将功能安全交付上线的独立开发者与小团队。
潜在需求
需要一种能覆盖 AI 生成代码特有漏洞模式的安全检查，能过滤误报并直接生成可执行的修复建议，让开发者不必逐一人工研判高危告警就能放心发布。
发生场景
团队将 AI 生成的代码集成到产品并准备发布时，无法直接信任其安全性；通用开源安全扫描器会产出 CRITICAL/HIGH 发现，其中包含误报，且缺少专门针对 AI 生成代码中 RLS、Secrets、Buckets、Mass-assignment 等模式的安全规则。
来源证据
项目作者表示，其安全扫描器以开源安全工具为引擎，并自行编写了 29 条针对 AI 生成代码常见安全模式的规则；检测全部确定性，AI 层只负责审查 CRITICAL/HIGH 误报和生成修复。
What's under the hood, because "AI security scanner" do deserves the suspicion. We use opensource security tools (the security engine), 29 security rules that I wrote for the most patterns that show up specifically in AI-generated code : RLS, Secrets, Buckets, Auth, Mass-assignment, Webhooks, CORS, Debug, Randomness, Ownership and Vulnerable dependencies Our AI layer does two jobs and neither is finding bugs. It reviews CRITICAL and HIGH findings for false positives and it writes the fix.https://news.ycombinator.com/item?id=49564974
为什么值得留意
该信号把“AI 生成代码的安全风险”做成了具体可操作的问题：列出 29 个由作者归纳的特定模式，并采用“确定性检测 + AI 处理误报与修复”的架构。这对后续做规则集合、CI 集成或误报治理类工具是一个直接的参照点，也容易向开发者说明价值。
已有方案
- 开源安全扫描工具（作为项目安全引擎）
未满足部分
- 作者需要自行编写 29 条针对 AI 生成代码的安全规则，说明通用开源工具没有覆盖 RLS、Secrets、Buckets、Mass-assignment 等模式。
可能延伸 · 模型推测
- 将 29 条规则整理成可复用的规则包或社区维护的集合（模型推测）
- 把误报过滤与修复建议流程接入主流 CI/CD 流程（模型推测）
- 按技术栈或框架细化 AI 生成代码的专属检查规则（模型推测）
目前未知
- 信号来自项目作者自述，尚无独立用户采用或反馈证据
- 未提供误报率、规则有效性或扫描性能等验证数据
- 不确定这些 AI 代码漏洞模式在开发者中的实际出现频率
继续核实
- 使用 AI 生成代码的开发者是否在实际发布中遇到安全扫描误报率高或规则缺失的问题？
- 现有开源安全工具（如 Semgrep、CodeQL）对 AI 生成代码漏洞模式的覆盖情况如何？
- Sentrint 是否有独立用户使用，其误报过滤和自动修复的实际效果如何？
主题词
ai generated codesecurity scanningfalse positivesvulnerability patternsautomated fix