2026 年 8 月，GitHub 公布了「开源安全基金」（GitHub Secure Open Source Fund）第 4 期的成绩单。这项计划做的事情很直接：给开源项目发钱、派安全专家、配 AI 工具，帮维护者把项目安全补起来。第 4 期共资助 50 个开源项目、71 位维护者，覆盖 22 个国家，资助总额超过 50 万美元；结项时 92% 的项目已启用 GitHub 的核心安全功能。
对普通开发者来说，这份成绩单最有价值的部分不是钱，而是它反复验证的一套安全基线：基金怎么运作、五个核心安全功能各是什么、累计数据说明了什么、以及维护者能直接照抄什么，下面逐一展开。
基金在做什么
开源项目大多是维护者用业余时间维护，安全常被挤到末位：漏洞没人审、密钥不小心提交进仓库、依赖库过期无人管。GitHub 安全基金想验证一件事：给维护者配上资金、专家和工具，项目安全能否在一年内获得实质提升。
每期运作方式相同：先是三周集中冲刺，课程由 GitHub 安全实验室专家设计，按周分三个主题——开源安全基础、威胁建模与安全编码、AI 安全与漏洞管理；随后进入 12 个月参与期。每个项目获得 1 万美元：冲刺期 6000 美元，第 6 个月和第 12 个月各 2000 美元的安全复查费。此外，维护者还能参加安全专家坐班的社区答疑，并获得云基础设施额度。
92% 项目完成的安全基线：五个功能
92% 的项目结项时启用了以下五项核心安全功能，它们构成一个可复制的基线：
- 密钥扫描（secret scanning）：自动检测提交进代码的 API 密钥、密码、令牌。这类敏感信息一旦进入公开仓库，任何人都可能拿去冒用你的账号，扫描能在被滥用前发现并提示移除。
- 代码扫描（code scanning）：在仓库里接入静态分析，每次提交代码自动查找常见漏洞模式。报告使用的引擎是 CodeQL，它把代码当作数据做查询，能发现跨文件的漏洞模式。
- 受保护分支（protected branches）：给主分支加规则，如禁止直接推送、要求代码评审通过才能合并，防止未审代码进入主干。
- 私有漏洞报告（private vulnerability reporting）：允许安全研究者私下提交漏洞，而不是直接在 issue 公开细节，给维护者留出修复时间窗。
- 依赖自动更新（Dependabot）：自动监测第三方依赖，发现新版本或已知漏洞时自动发起更新请求并附修复建议。
四期累计的成绩
把全部四个期次和后续跟踪期加在一起：188 个项目、290 位维护者、42 个国家参与，GitHub、微软等共投入 188 万美元；参与项目披露了 533 个新 CVE、完成了 1500 多次 Dependabot 安全更新、解决了 650 多个暴露的密钥。截至 2026 年 7 月的最近 6 个月，各期参与项目与校友项目修复了 4210 个 CodeQL 告警，并拦截了 119 个险些公开的密钥。
CVE（Common Vulnerabilities and Exposures）是业界对安全漏洞的公开登记编号，一个 CVE 对应一个被确认并记录的漏洞，公开披露是为了让所有使用者都能及时知道并修复。这些数字指向同一个结论：资金、专家和工具到位后，安全问题可以被成规模地清理。
AI 的角色：提速，不替代判断
报告里贯穿始终的结论是：AI 能帮维护者调查、排序、更快响应安全问题——例如先由 AI 对漏洞告警做分类，筛出最该优先处理的条目；但最终仍由维护者提供上下文、做出判断、承担责任，决定什么代码可以发布。AI 安全不是游离在外的全新问题，而是正在融入「构建安全软件」的整体实践。
本期 AI 类项目中，还包含今年增长最快的开源项目 OpenClaw：它在期内制定了事件响应计划、扩展了安全工具的使用，并审计了自己的 GitHub Actions 自动化工作流。
维护者可以直接照抄的四条
把这份成绩单背后的做法压缩成行动清单：
- 先打开安全五件套——全部在仓库设置里免费启用，不需要任何资助；
- 用三周式的集中冲刺处理积压的安全事项，比零散修补更有效；
- 用 AI 工具做漏洞初审与排序，保留人工判断和问责；
- 把密钥清理、依赖更新固化为例行流程，而不是应急动作。
开源安全不是靠少数专家，而是靠一套可复制的流程加工具，辅以少量资金，一年内就能看到 92% 的完成率。 对单个维护者来说，不必等基金资助——先打开五件套，就走完了报告里绝大多数项目走的那一步。