デプロイパイプラインにセキュリティゲートを組み込む方法（GitHub Actions編）

「次回からはデプロイ前に必ず確認します」——この決意はだいたい3回目のデプロイあたりで忘れられます。人の意志に頼るチェックは、結局失敗します。答えはチェックを自動化し、失敗したらデプロイ自体を止めることです。

なぜ「確認します」は失敗するのか

忙しいとき、急いでいるとき、金曜の午後にデプロイするとき——人はチェックリストを飛ばします。一度飛ばして何も起きなければ、次はもっと簡単に飛ばすようになります。これは怠慢の問題ではなく、構造の問題です。人が毎回覚えていないと守れないルールは、いずれ破られます。

ゲートとは何か

「ゲート」はシンプルです。チェックが失敗したらマージやデプロイを止めること。人が確認を忘れても、パイプラインが代わりに止めてくれます。突破するには問題を実際に直すしかありません。

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はマージ前に赤いバツ印が表示されます。ここにシークレットスキャンやSAST（静的解析）のステップを加えれば、カバー範囲がさらに広がります。

何をゲートにかけるべきか

すべてを止めてしまうと誰もデプロイできなくなります。優先順位を決めましょう。

• 必ずブロック：ハードコードされたシークレット、Critical/High等級のCVE
• 警告のみ：Low/Medium等級、スタイルの問題
• 段階的に強化：最初は警告だけ表示し、チームが慣れたらブロックに切り替える

誤検知を放置するとゲートが機能しなくなる

ゲートが頻繁に間違えると、チームは「また誤検知か」と回避策を探し始めます（例：チェックスキップフラグを習慣的に使う）。誤検知率を低く保つことがゲートを長く生かす鍵です。必要であれば、例外は明示的なリストとして管理してください——黙って無効化するよりずっと良い方法です。

WhiteHat CodeはGitHubリポジトリを連携すると、プッシュ・PRのたびに自動でスキャンし、深刻度別に結果を整理して見せてくれます。自分でゲートを組む必要なく、すぐに始められます。