01 它是干嘛的
这套能力把安全检查提前到写代码的阶段：一边读你的代码找出可能被利用的写法，一边比对依赖清单里哪些第三方库已经爆出漏洞，同时盯着提交里有没有混进密钥，并把结果直接写在合并申请上。它针对的是「漏洞在线上被发现时，修的成本已经是当初的几十倍」。
02 为什么会有它
漏洞被发现的时刻，决定了修它的代价
传统做法里，安全检查是在上线之前甚至上线之后做的：渗透测试、扫描器、外部报告。问题是到那个阶段，代码已经定型、被很多人依赖，改一处可能牵动全局。同一个漏洞，在写下的当天修可能只是改两行，在线上被利用之后再修，代价是前者的几十倍。
更常见的一类问题甚至不是自己写的：现代项目里八成以上的代码来自第三方依赖，其中任何一个爆出漏洞，你的产品就跟着中招。项目动辄几百个依赖，靠人定期去比对「有没有出新漏洞」根本不现实。
还有一类代价最高的低级事故：密钥被顺手提交进了仓库。哪怕随后删掉，历史记录里仍然留着，只能作废重发；如果那个仓库是公开的，等于把钥匙挂在了门口。GitHub 从 2019 年起把这几类检查内建进平台，让它们在提交与合并的环节就自动跑，而不是等到有人来敲门。
03 它怎么工作
代码提交后，平台并行跑几条扫描：分析代码写法、比对依赖清单的风险情报、在新增内容里找密钥特征，再把发现按严重程度标注在合并申请的具体行上，必要时直接阻止合并。
一次合并申请会经过哪几道安全检查
- 1① 变更触发扫描
提交或合并申请一出现就启动扫描，只针对本次改动及其影响范围，不必等全量扫描。
- 2② 静态分析找可疑写法
把代码转换成可分析的结构，顺着数据从输入到执行的通路，找出可能被注入或越权的写法。
- 3③ 比对依赖风险情报
读取依赖清单与锁定文件，和公开的漏洞数据库对照，列出受影响的库与升级目标版本。
- 4④ 检查密钥与令牌
在新增内容里识别密钥特征，并向对应服务商核实它是否仍然有效，减少误报。
- 5⑤ 标注并阻断
把问题写回合并申请的具体代码行，按严重程度排序；配置为必过项时，问题未处理不允许合并。
04 谁在用它
把安全检查设为合并的硬性条件，问题代码进不了主线。
第三方库爆出漏洞时，第一时间知道哪些仓库受影响、该升到哪个版本。
提交里出现密钥立即拦下，避免已经公开、只能作废重发的被动局面。
为外部审计提供「什么时候发现、多久修好」的完整记录，而不是靠人工整理。
对多年没人动过的仓库做一次整体扫描，先看清历史欠账有多大。
05 怎么用
仓库管理员在设置里开启即可，开发者主要在合并申请页面上接收与处理结果。
- 01在仓库设置里开启代码扫描、依赖审查与密钥检查。
- 02先用一段时间「只报告不阻断」，摸清基线，避免一上来就卡住所有合并。
- 03按严重程度定处理规则：高危必须修，低危排期处理，误报逐条标记忽略。
- 04依赖漏洞优先处理有现成升级版本、且在生产依赖链上的那几条。
- 05把密钥检查设为主线必过项，并提醒团队改用环境变量与密钥托管。
- 06定期回看统计：平均修复时长比「一共发现多少个问题」更能说明安全状况。
# 仓库设置 → 分支保护规则中勾选：
# Require status checks to pass before merging
# 并选中 Code scanning / Dependency review / Secret scanning
# 也可以在工作流里显式加一道依赖审查
name: 依赖审查
on: pull_request
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/dependency-review-action@v4
with:
fail-on-severity: high避坑提示
- !一上线就全面阻断会招致团队反感：先观察一段时间，把误报和规则调准再收紧。
- !依赖漏洞不要一律升到最新：先看是否在生产依赖链上、是否有破坏性变更。
- !密钥一旦提交过就当作已泄露，作废重发，别指望删掉提交就能收回。
06 关键概念
- 静态分析
- 不运行程序，只读代码结构就能找出一部分危险写法与逻辑漏洞。
- 依赖漏洞
- 你用的第三方库自身存在的安全缺陷，你的产品会连带受影响。
- 密钥泄露
- 密码、令牌等凭据被写进代码并提交，任何能看到仓库的人都可能拿到。
- 分支保护
- 对主分支加规则：必须通过评审与检查才能合并，防止绕过流程。