Contents
GitHub Actionsでセキュリティスキャンを導入する意義
ソフトウェアサプライチェーン攻撃の頻度が過去最高となる中、CI/CDパイプラインにおける脆弱性検出の自動化は企業にとって不可欠な課題となっています。GitHub Actionsを活用したセキュリティスキャンは、依存関係のリスクやクラウドプロバイダーとの接続安全性を即時で把握できる仕組みです。本記事では、実務で導入可能なワークフロー構成と設定手順を解説します。読者の方は、この記事を通じて「GitHub Actions セキュリティ スキャン 設定方法」に関する具体的な知識を得られることでしょう。
OpenID Connect認証によるクラウドプロバイダー連携
セキュアなCI/CD構築の第一歩として、OpenID Connect（OIDC）を用いたクラウドプロバイダーとの接続設定が推奨されています。AWSやGCPなど外部リソースへのアクセスにおいて、暗号化されたトークン認証で安全性を担保する仕組みとして必須となっています。
OIDCの仕組みとGitHub Actionsとの統合手順
OIDCは、GitHub Actionsがクラウドプロバイダーにアクセスする際に短期間有効なトークン（JWT）を発行して認証を行う方式です。これにより、機密情報やAPIキーの直接的な記載が不要になります。
以下は、AWSとの接続設定の手順です：
- GitHubリポジトリにOIDCプロバイダーとしての設定を追加します（公式ドキュメント）。
- AWS IAMからGitHub Actions用のロールを作成し、 OIDCトークンの検証条件を指定します。
- GitHub Actionsワークフロー内に
aws-actions/configure-aws-credentialsを使用して認証情報を注入します。
OIDCとの統合は、リソースへのアクセス権限の最小化と認証情報漏洩リスクの低減を実現するための核となる技術です。
依存関係スキャンワークフローのベストプラクティス
依存関係スキャンを行う際には、DependabotとSnykの併用が推奨手法です。それぞれが異なるアプローチで脆弱性を検出するため、漏れを防ぐことができます。
DependabotとSnykの併用構成例
| ツール | 検出対象 | 特徴 |
|---|---|---|
| Dependabot | パッケージバージョン | GitHub自身が提供し、依存関係の最新化を自動で提案 |
| Snyk | セキュリティ脆弱性 | 外部ライブラリやコンテナイメージなど幅広い対象をスキャン |
以下は、YAMLファイルでの基本構成例です：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
name: '依存関係スキャン' on: push: branches: [main] pull_request: branches: [main] jobs: dependabot-scan: runs-on: ubuntu-latest steps: - name: Dependabotを実行 uses: dependabot/dependabot-core@v1 snyk-scan: runs-on: ubuntu-latest steps: - name: Snykスキャン uses: snyk/actions/snyk-code@v3 with: args: scan |
このように組み合わせることで、依存関係のバージョン管理とセキュリティリスクの両面からプロジェクトを守る事が可能になります。
GitHub Secretsの高セキュリティ管理手法
GitHub Actionsでは、環境変数やAPIキーなどの機密情報は GitHub Secrets に保存することが推奨されます。以下のような管理方法が重要です。
暗号化技術とロールベースアクセス制御(RBAC)
- AES-256による暗号化：Secretsはリポジトリごとに個別に暗号化され、外部からの参照を防ぎます。
- RBACの導入：特定のワークフローのみがSecretsにアクセスできるように設定することで、リスク拡大を最小限に抑えます。
具体的な手順は以下の通りです：
- GitHubリポジトリ内の「Settings」→「 Secrets and variables」からシークレットを登録します。
- ワークフローのYAMLファイル内で
${{ secrets.API_KEY }}の形式でアクセスします。 - 組織レベルでの権限管理（例:
read_secretsロール）を設定し、不要なユーザーのアクセスを制限します。
GitHub Secretsは、クラウド環境に保存されるため、リポジトリの公開状態に関係なく安全に管理できます。
ソフトウェアビルディングブロック(SBB)の検証フロー
近年のサプライチェーン攻撃では、ソフトウェアビルディングブロック（SBB）の検証が鍵となっています。OWASPが発表したガイドラインには、依存関係の「信頼性」「透明性」「更新履歴」を確認する3つのプロトコルが推奨されています。
SBB検証フロー
- 信頼性の確認：ライブラリやコンテナイメージの提供元（例: npm、Maven Central）に信頼性を評価する
- 透明性の確保：ビルドプロセスとコード履歴が公開されているかをチェック
- 更新履歴の可視化：バージョン管理システムで過去の変更内容やリスクを一覧できるようにする
これらの対策は、GitHub Actions内で以下のように実装できます：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
name: 'SBB検証' on: push: branches: [main] jobs: verify-sbb: runs-on: ubuntu-latest steps: - name: パッケージの信頼性確認 uses: actions/dependency-check@v2 with: type: 'npm' |
自動化された脆弱性検出と通知体制構築
GitHub Actionsの最大の利点は、検出→分析→対応のプロセスを完全に自動化できる点です。SlackやTeamsとの連携により、即時で対応が可能になります。
Slack/Teams連携による即時対応フロー
具体的な構成例は以下の通りです：
- SlackアプリのインストールとWebhook URLの取得
- GitHub Actionsワークフローより、検出結果を
slack-notifyアクションで送信する - チームメンバーが通知を受けて、即時対応を行う
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
name: '脆弱性検出と通知' on: push: branches: [main] jobs: notify: runs-on: ubuntu-latest steps: - name: Slackに通知 uses: slackapi/slack-notify-action@v1.2 with: status: 'Vulnerability detected' message: 'Snykスキャンで問題が検出されました。詳しくはhttps://example.comを参照ください。' |
このようにすることで、セキュリティリスクの即時対応とチーム間の情報共有を効率化できます。
まとめ
本記事では、GitHub Actionsによるセキュリティスキャン導入の意義から具体的な構成方法まで解説しました。重要なポイントは以下の通りです：
- OpenID Connect（OIDC）認証はクラウドプロバイダーとの安全な接続を実現する必須技術
- DependabotとSnykの併用で、依存関係スキャンを高精度に実施できます
- GitHub Secretsの厳格な管理により、機密情報の漏洩リスクを最小化します
- ソフトウェアビルディングブロック（SBB）検証フローがサプライチェーン攻撃対策として推奨されています
- SlackやTeamsとの連携で、脆弱性検出後の即時対応体制を構築できます
これらの知識とワークフローテンプレートは、GitHubリポジトリに保存し、即日導入を開始してください。