如何在部署流水线中加入安全门禁（以GitHub Actions为例）

"下次一定会在部署前确认"——这个承诺通常撑不过第三次部署就被忘光了。依赖人的意志力来做检查，最终一定会失败。答案是把检查自动化，失败时直接拦截部署本身。

为什么"我会确认"注定失败

忙碌的时候、赶时间的时候、周五下午要部署的时候——人就会跳过检查清单。跳过一次没事，下次就更容易跳过。这不是懒惰的问题，而是结构性问题。需要人每次都记得才能维持的规则，终究会被打破。

什么是门禁

"门禁"很简单：检查失败，就拦截合并（merge）或部署。 即使人忘记确认，流水线也会代为拦截。要通过，唯一的办法就是真正修好问题。

在GitHub Actions中最精简的做法

可以先在仓库中新增一个.github/workflows/security.yml文件开始。

name: security-gate
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run dependency audit
        run: npm audit --audit-level=high

光是这一步，存在高危漏洞的PR在合并前就会显示红色X标记。 再加上密钥扫描、SAST（静态分析）步骤，覆盖范围会更广。

什么该设为门禁

全部都拦截的话就没人能部署了。请定出优先级。

• 必须拦截：硬编码的密钥、Critical/High级别的CVE
• 仅显示警告：Low/Medium级别、风格问题
• 逐步收紧：一开始只显示警告，等团队适应后再切换为拦截

放任误报不管，门禁就会失去作用

如果门禁经常判断错误，团队就会觉得"又是误报"，开始寻找绕过的方法（例如习惯性使用跳过检查的标志）。保持较低的误报率是让门禁长久有效的关键。如果确实需要例外，请把它明确列成清单管理——这比悄悄关掉检查好得多。

WhiteHat Code只要连接GitHub仓库，就会在每次推送、PR时自动扫描，并按严重程度整理结果展示。不用自己搭建门禁，就能立刻开始使用。