6 security settings every GitHub maintainer should enable this week

好的，没问题。这篇博客文章写得挺实在的，但确实可以更“技术笔记”一点。下面我把它重新组织一下，就像是我自己折腾完项目安全配置后，顺手写的分享。咱们直接开始。

---

最近跟几个维护开源项目的朋友聊天，发现一个普遍现象：大家要么觉得 GitHub 的设置页面太复杂，要么就是文档太多根本看不完。说白了，大部分项目维护者都不是专职的安全工程师，这很正常。但问题在于，如果你完全不管项目的安全设置，就等于放弃了自动化和规模化防御的能力。结果就是安全态势越来越差，漏洞越积越多，最后坑的还是你的用户。

GitHub 官方其实给了个叫 Protect Your Project 的引导流，把这六个设置打包在一起，半小时内就能搞定。但我觉得，光点按钮不够，得知道每个设置背后到底在干什么。下面我用自己的理解，把这六个点掰开揉碎了讲一遍。

1. 加个 SECURITY.md 文件：给漏洞报告者指条明路

这是最轻量级，但也是让后续所有设置生效的前提。没有它，好心发现你项目有 Bug 的人，要么直接提一个公开 Issue（等于把漏洞曝光了），要么费劲巴拉去找你的个人邮箱。

你不需要写一篇论文。核心就三件事：

1. 明确沟通渠道：比如一个专用的邮箱地址。让报告者能直接联系到你，而不是把漏洞细节扔到公共区域。
2. 界定范围：哪些类型的漏洞是你在意的？比如 SQL 注入、命令执行，还是包括一些配置问题？说清楚，避免对方报告一堆你压根不关心的东西。
3. 设定预期：别假设你有个 24/7 的安全响应团队。告诉对方你大概多久会回复，需要什么样的复现步骤（Reproducer）。

一个不错的参考例子： systemd 项目的安全策略。它把“需要什么信息来复现漏洞”写得很清楚，而且非常务实，没给自己画大饼。

操作步骤：
在你的仓库根目录下新建一个 SECURITY.md 文件，把上面三点写进去。比如我自己的项目，我会这样写：

# Security Policy

## Reporting a Vulnerability

If you discover a security vulnerability in this project, please do **not** open a public issue. Instead, send an email to [security@myproject.dev](mailto:security@myproject.dev).

We aim to acknowledge receipt of your report within 48 hours and will work with you to understand the issue and its impact. We ask that you give us a reasonable time to fix the issue before disclosing it publicly.

## Scope

This policy covers the core project and its officially maintained plugins. Issues in third-party dependencies should be reported to the respective maintainers.

## What we need from you

- A clear description of the vulnerability.
- Steps to reproduce it, including any specific configuration or environment details.
- Proof-of-concept code, if applicable.

十分钟，搞定。

2. 开启私有漏洞报告（PVR）：给报告者一个安全的“小黑屋”

SECURITY.md 告诉人家“往哪走”，而私有漏洞报告（Private Vulnerability Reporting, PVR） 则给了他们一个“可以安全说话的地方”。

开启后，研究人员可以直接在你的仓库里提交一个机密性建议（Confidential Advisory）。这个建议只有你和报告者能看到。你可以私下里处理它，修复、验证，然后在你认为合适的时间点，选择性地公开披露。

为什么这俩必须一起开？
因为 SECURITY.md 是“路标”，PVR 是“会客厅”。没有路标，人家找不到门；没有会客厅，人家只能站在大街上喊（提公开 Issue）。这俩是给社区最直接、最强烈的信号：你认真对待安全问题。

操作步骤：
Settings -> Security -> Private vulnerability reporting，把那个复选框勾上。就一步。

3. 开启密钥扫描（Secret Scanning）并启用推送保护（Push Protection）：别让“不小心”毁了所有

这个设置是“最尴尬的失败模式”。GitGuardian 的《2026 年密钥泄露状况报告》显示，2025 年公开 GitHub 上泄露了 2865 万个新密钥，同比暴增 34%。而且，AI 辅助提交的代码，泄露密钥的概率是普通代码的两倍。IBM 的报告说，一次数据泄露的平均成本全球是 444 万美元，在美国更是高达 1022 万美元。

它到底怎么工作的？

• 密钥扫描（Secret Scanning）：GitHub 会在后台扫描你的仓库（包括历史提交），看看有没有像 AWS Key、GitHub Token、数据库密码这类东西。发现了就给你发警报。
• 推送保护（Push Protection）：这才是关键。它在你 git push 的时候，在本地就拦截住包含密钥的提交。你还没把脏东西推上去，就被拦下来了。这比事后扫描要有效得多。

为什么推送保护至关重要？
因为一旦密钥被推送到仓库（即使是私有仓库），它就存在于 Git 历史里了。任何有仓库访问权限的人，都能通过 git log 或 git blame 翻出来。等你发现报警再轮转密钥，黄花菜都凉了。

操作步骤：
Settings -> Security -> Secret scanning -> 勾选 Enable secret scanning，然后勾选 Enable push protection。

一个重要的点： 别以为你的仓库是私有的就安全。私有仓库里泄露的密钥，同样能被内部人员或未来获得访问权限的人利用。

4. 开启 Dependabot 和依赖审查：你的项目不只是你的代码

你的项目 = 你的代码 + 几十上百个你引用的第三方包。你不可能审查所有依赖的代码，但你可以让 Dependabot 帮你盯着。

比如 WordPress，搜一下就知道有多少已知漏洞的插件。如果你在跑 WordPress，Dependabot 能确保这些有漏洞的插件不在你的依赖列表里。

它俩是怎么配合的？

• Dependabot：它会持续监控你的 package.json、Gemfile、requirements.txt 等依赖文件。一旦发现某个依赖有已知的 CVE（通用漏洞披露），它会：

  1. 给你发警报。
  2. 自动创建一个 Pull Request，尝试把有漏洞的依赖升级到安全版本。

• 依赖审查（Dependency Review）：这个功能更“实时”。当你打开一个 Pull Request 时，它会在 PR 的 “Files changed” 标签页里，清晰展示这个 PR 新增或修改了哪些依赖，以及这些依赖是否有已知的安全漏洞。它把一个模糊的 package.json diff，变成了一个两分钟就能看完的安全审计报告。

操作步骤：
Settings -> Security -> Dependabot -> 启用 Dependabot alerts 和 Dependabot security updates。然后在 Code security and analysis 里启用 Dependency graph（这是依赖审查的基础）。

5. 开启代码扫描（Code Scanning）：让 AI 帮你找 Bug

代码扫描本质上是静态分析（SAST）。它会在你每次提交或 PR 时，自动扫描你的代码，找出那些容易导致真实漏洞的代码模式。比如：SQL 注入、命令注入、不安全的反序列化…… 这些都是老面孔了。

GitHub 的代码扫描用的是 CodeQL，这是他们自己造的引擎。2019 年就免费开放给开源项目了。现在它甚至进化成了“一键默认设置”。

为什么很多人会跳过它？
因为听起来好像需要配置一堆规则文件。其实完全不需要。

• 默认设置（Default Setup）：你只要在仓库的 Settings -> Code security and analysis 里，找到 Code scanning，点 “Set up” -> “Default”。CodeQL 会自动识别你的编程语言（Python, JavaScript, Java, Go, C++ 等），并选择最合适的查询包（query pack）。你唯一要做的就是点一下确认。
• 它做了什么？ 它会分析你的代码，构建一个数据流图，然后运行一系列安全查询（比如“检查用户输入是否被不安全地拼接到 SQL 查询中”）。如果发现匹配，就会在 PR 的 “Checks” 标签页里标红，并给出详细的告警信息和修复建议。

操作步骤：
Settings -> Code security and analysis -> Code scanning -> Set up -> Default -> 选择 Default 并确认。

6. 开启分支保护（Branch Protection）：给所有安全措施上“锁”

这是最朴实无华，但影响最大的设置。它就像你家的门锁——简单，但能拦住绝大多数不怀好意的人。

核心规则：
在默认分支（通常是 main 或 master）上，要求 Pull Request 审核，并且至少需要一个人批准才能合并。

为什么这能产生最大影响？

1. 阻止最坏情况：它能拦住“一个被攻陷的账户”、“一个糊涂的贡献者”或者“一个疲惫不堪的你自己”直接往生产环境 push 代码。强制 PR 流程，给了你一次“停下来想一想”的机会。

2. 让其他五个设置“生效”：这才是关键中的关键。如果你只开了 Dependabot 和代码扫描，但没有分支保护，那么 Dependabot 的警报和代码扫描的告警，只会静静地躺在某个你永远不会打开的标签页里。但是，一旦你启用了分支保护，并配置了“要求状态检查通过”，那么：

   • 一个包含有漏洞依赖的 PR，Dependabot 会把它标记为“不通过”。
   • 一个存在 SQL 注入风险的代码变更，代码扫描会把它标记为“不通过”。
   • 这些 PR 将无法被合并！

   分支保护，把安全扫描从“建议”变成了“强制规则”。

操作步骤：
Settings -> Branches -> Add branch protection rule -> 在 Branch name pattern 里输入你的默认分支名（比如 main） -> 勾选 Require a pull request before merging -> 勾选 Require approvals 并设置 Required number of approvals before merging 为 1 -> 强烈建议勾选 Require status checks to pass before merging，然后从列表里选择 Dependabot 和 CodeQL 的状态检查。

---

关于 Protect Your Project 这个工具

GitHub 官方弄了个引导流，就叫 Protect Your Project。它是个向导，带着你一步步在一个仓库里把这六个设置都走一遍，大概 10-15 分钟。如果你不想自己记这些步骤，直接用那个工具就行。但理解每个设置背后的原理，能让你在遇到问题时，知道该怎么调整。

最后说两句

这六个设置不会让你的项目变得“不可攻破”。没有任何东西能做到这一点。但它们能关掉那些最容易走的门——那些正在被自动化脚本大规模扫描公共仓库的坏人正在走的门。

把这六个设置打开，你的项目在今天早上相比，就会难攻破得多。而所有依赖你项目的其他项目，也会因此变得更安全。