npm audit绿了不代表依赖真的安全——今天发现GitHub把扫描装进了PR这道门

npm audit 绿了不代表依赖真的安全——今天发现 GitHub 把它自己的那道门直接装到了 PR 里。

前几天刚扒完 SANDWORM_MODE 供应链蠕虫，团队上了心开始查依赖扫描。但扫了一阵发现一个问题：npm audit 只能扫直接依赖，间接依赖（transitive dependency）有漏洞时，audit 报告经常是绿的。这就是为什么很多项目明明依赖有 CVE，团队却完全不知道。

GitHub 的 dependency-review-action 就是来解决这个问题的。

装上之后，每一次 PR 都会自动扫描这次改动涉及的所有依赖——包括直接依赖和间接依赖——如果有任何 CVE 漏洞或者不合规的开源许可，直接把 PR 标红，merge 都点不下去。

workflow 配置就这几行：

name: "Dependency Review"
on: [pull_request]

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4

不需要额外的 API Key，公开仓库直接用，私有仓库需要 GitHub Advanced Security 许可。

数据来源是 GitHub Advisory Database 和 OSV（Open Source Vulnerabilities）格式打通的，覆盖范围比 npm audit 宽。CVE 不用说，连一些还没进 CVE 数据库但已经被社区标记的漏洞也会扫到。许可合规是另一层——有些开源项目用的许可证在你们公司其实是禁止的，这个 audit 不会管但 dependency-review-action 会。

实际扫出来的情况分两种：一种是你这次 PR 直接升级了一个有漏洞的包，action 会标出是哪个包哪个版本升级引入了漏洞，定位非常精准；另一种是你这次 PR 本身没改依赖，但 base branch 侧有漏洞，action 也能检测到，这属于更主动的防护。

局限要说清楚：它扫的是 manifest 和 lockfile 的变化，不是跑一个实时漏洞监控——所以它解决的是「这次代码改动有没有引入新漏洞」，不是「我的整个依赖树现在是否干净」。实时漏洞监控要配合 GitHub Dependabot 或者 Snyk 这类工具一起用。

下一步：先在你们主仓库的 workflow 里加这一个 action，跑一个月看看它实际拦掉了多少 PR。这一个月的数据，决定了你们供应链安全基线要搭多高。