近期，在开发者圈子中流传着一个未经证实的消息，称Linux基金会获得了1250万美元的资助，旨在应对低质量的AI生成安全报告。截至目前，这一“Linux基金会1250万美元资助”的说法尚未得到官方来源的确认。
AI生成的安全报告对开源维护者的重要性
AI工具虽然能加速代码审查及模糊测试，但也增加了噪声：诸如重复问题、错误分类的严重性以及缺乏证据的漏洞声明。这不仅提升了问题处理成本，还延长了解决时间，分散了稀缺审核人员的精力，使其无法专注于真正的缺陷。
Stenberg的经验突显了平衡的重要性。AI辅助工具虽然能暴露出真实缺陷，但错误警报率的上升以及外部工作负担对志愿者和人手不足的团队产生了最为显著的影响。
如果Linux基金会的资助未被确认，将产生的直接影响
如果没有任何确认，项目应围绕现有能力和治理进行规划，而非期待新的Linux基金会资金支持。近期内，信号与噪声的比例将取决于严格的分类和更清晰的提交标准，而不是假设的资助。
在漏洞报告中负责任地使用AI
AI生成的低质量报告与真实发现的信号
低质量报告通常包含模板化的漏洞语言、无依据的严重性声明、缺乏项目背景的CVE/CWE文本，以及缺失的概念验证或再现步骤。它们常常错误识别受影响版本、在示例中误用API，或将配置风险与代码级缺陷混淆。
而真实的AI辅助发现则有所不同：它们会注明AI的使用，提供最小化的可重现测试用例，明确受影响的版本和环境，并为CWE映射和CVSS提供与项目行为相关的理由。
改进报告质量的模板和政策要求
一个完善的漏洞披露政策应要求：明确受影响组件和版本、精确的重现步骤、自包含的概念验证、预期行为与实际行为的对比、环境细节，以及附带理由的CWE/CVSS建议。政策还应要求报告者披露是否使用了AI工具，列出所有应用的自动化扫描器或提示，并提供协调披露的联系信息。
过程护栏能够帮助：需确认问题在当前主版本和最新稳定版本中可重现，筛选出重复的签名，并定义禁运和沟通的时间框架。结构化的进件流程能够将模糊的叙述转变为可验证的证据。
关于AI生成安全报告的常见问题
维护者如何识别AI生成或低质量安全报告的常见模式？
要关注模板化的文本、缺乏概念验证、版本不匹配、无理由的CWE/CVSS复制及缺乏可重现步骤的严重声明。
哪些分类工作流和漏洞披露政策的更新能帮助减少这一问题？