GitHubサプライチェーンセキュリティ完全ガイド

Last updated at 2025-12-21Posted at 2025-12-21

GitHubサプライチェーンセキュリティ完全ガイド

ソフトウェア開発において、サプライチェーンセキュリティは避けて通れない課題となっています。オープンソースライブラリやフレームワークへの依存が深まる中、一つの脆弱性が連鎖的に影響を及ぼすリスクが高まっています。

この記事では、GitHubが提供するサプライチェーンセキュリティ機能の全体像を、実践的な視点から解説します。

1. サプライチェーンセキュリティとは

ソフトウェアプロジェクトは、オープンソースライブラリ、フレームワーク、ビルドツールなど、数百もの依存関係を持つことが一般的です。これらの依存関係全体が「サプライチェーン」を形成しています。

サプライチェーンにおける脅威は主に3つです：

脆弱性のある依存関係の使用：既知の脆弱性を持つライブラリを使い続けること
認証情報の漏洩：GitHubにコミットされたAPIキーやパスワード
コード自体の脆弱性：自分たちが書いたコードに含まれるセキュリティ上の弱点

GitHubは、これらの脅威に対応するための包括的な機能セットを提供しています。

2. GitHubのサプライチェーンセキュリティ機能の全体像

依存関係グラフが中心となり、他のすべての機能がそこから派生する構造になっています。この設計により、一貫性のある依存関係管理が実現されています。

3. 依存関係グラフ：すべての基盤

依存関係グラフは、リポジトリ内のマニフェストファイルやロックファイルを自動的に解析し、プロジェクトが依存しているパッケージの全体像を可視化します。

3.1 主な特徴

自動更新：デフォルトブランチへのコミット時に自動的に更新
推移的依存関係の追跡：直接指定していない、依存関係の依存関係も追跡
脆弱性情報の統合：各依存関係の既知の脆弱性を表示
ライセンス情報：依存関係のライセンスを一覧表示

3.2 サポートされるエコシステム

パッケージマネージャー	言語	推奨ファイル	追加ファイル
Cargo	Rust	Cargo.lock	Cargo.toml
Maven	Java, Scala	pom.xml	-
npm	JavaScript	package-lock.json	package.json
pip	Python	requirements.txt, pipfile.lock	pipfile, setup.py
RubyGems	Ruby	Gemfile.lock	Gemfile, *.gemspec
Go modules	Go	go.mod	-
Gradle	Java	-	build.gradle
NuGet	.NET	.csproj, .vbproj	packages.config
Composer	PHP	composer.lock	composer.json
Poetry	Python	poetry.lock	pyproject.toml
pnpm	JavaScript	pnpm-lock.yaml	package.json
Yarn	JavaScript	yarn.lock	package.json

3.3 有効化方法

パブリックリポジトリでは、依存関係グラフはデフォルトで有効です。プライベートリポジトリの場合：

リポジトリの Settings タブへ移動
Security セクションの Advanced Security をクリック
Dependency Graph の横にある Enable をクリック

3.4 依存関係の確認

Dependencies タブでは、以下の情報が確認できます：

パッケージ名とバージョン
エコシステム（npm、Maven等）
マニフェストファイルの場所
ライセンス情報
既知の脆弱性の有無
関係性（直接 or 推移的）

検索バーを使用して特定の依存関係を検索でき、脆弱性のあるパッケージは自動的にリストの上位に表示されます。

4. 依存関係サブミッション：ビルド時の依存関係も追跡

静的解析だけでは、ビルド時に解決される推移的依存関係を完全に把握できないエコシステムがあります。依存関係サブミッションAPIと自動依存関係サブミッション機能により、この課題を解決できます。

4.1 自動依存関係サブミッション

GitHub Actionsを使用して、ビルド時に解決される依存関係を自動的に検出し、依存関係グラフに送信します。

4.1.1 対応エコシステム

現在、以下のエコシステムで自動サブミッションが利用可能です：

Go
Java (Maven, Gradle)
.NET (C#, F#, Visual Basic)
Python

4.1.2 有効化手順

リポジトリの Settings → Security → Advanced Security へ移動
Dependency graph セクションの Automatic dependency submission ドロップダウンから Enabled を選択

有効化後、マニフェストファイルが更新されると自動的にアクションが実行され、依存関係情報が送信されます。

4.1.3 動作の仕組み

4.2 プライベートレジストリへのアクセス

自己ホストランナーを使用することで、プライベートMavenレジストリにアクセスできます：

リポジトリまたは組織レベルで自己ホストランナーをプロビジョニング
各ランナーに dependency-submission ラベルを割り当て
Automatic dependency submission を Enabled for labeled runners に設定

Maven/Gradleプロジェクトでプライベートレジストリを使用する場合、依存関係サブミッションワークフローがレジストリに接続できるよう、Maven設定ファイルを変更する必要があります。

4.3 手動サブミッション：既製アクションの活用

既製のGitHub Actionsを使用して、依存関係を手動でサブミットすることもできます：

エコシステム	アクション
Go	Go Dependency Submission
Gradle	Gradle Dependency Submission
Maven	Maven Dependency Tree Dependency Submission
Mix (Elixir)	Mix Dependency Submission
Scala	Sbt Dependency Submission
その他	Component Detection dependency submission action

4.3.1 Go の例

name: Go 依存関係サブミッション
on:
  push:
    branches:
      - main

permissions:
  contents: write

env:
  GOPROXY: ''
  GOPRIVATE: ''

jobs:
  go-action-detection:
    runs-on: ubuntu-latest
    steps:
      - name: 'リポジトリをチェックアウト'
        uses: actions/checkout@v5

      - uses: actions/setup-go@v5
        with:
          go-version: ">=1.18.0"

      - name: スナップショットアクションを実行
        uses: actions/go-dependency-submission@v2
        with:
            go-mod-path: go-example/go.mod
            go-build-target: go-example/cmd/octocat.go

4.4 マニフェストの重複排除

リポジトリで複数の方法（静的解析、自動サブミッション、手動サブミッション）を設定すると、同じマニフェストファイルが複数回スキャンされる可能性があります。

依存関係グラフは、以下の優先順位で重複を排除します：

ユーザーサブミッション（最優先）：ビルド時に作成され、最も完全な情報を持つ
自動サブミッション：ビルド時に作成されるが、ユーザーによる送信ではない
静的解析：他のデータがない場合に使用

5. Dependabot：自動化された脆弱性管理

Dependabotは、GitHubの依存関係管理の中核を担う機能です。脆弱性の検出から修正までを自動化します。

5.1 Dependabotの3つの機能

5.2 Dependabot アラート

依存関係グラフとGitHub Advisory Databaseを照合し、脆弱性を検出します。

5.2.1 アラートが生成されるタイミング

GitHub Advisory Databaseに新しいアドバイザリが追加されたとき
リポジトリの依存関係グラフが変更されたとき

5.2.2 有効化方法

パブリックリポジトリの場合、リポジトリ所有者または管理者権限を持つユーザーが有効化できます：

リポジトリの Settings → Security & analysis
Dependabot alerts の横にある Enable をクリック

プライベートリポジトリの場合、まず依存関係グラフを有効化する必要があります。

5.3 Dependabot セキュリティアップデート

Dependabotアラートがトリガーされたとき、自動的に脆弱性を修正するプルリクエストを作成します。

5.3.1 特徴

アラート駆動：Dependabotアラートがトリガーされたときに実行
最小限の更新：脆弱性を解決する最小バージョンに更新
設定ファイル不要（推奨はありますが、オーバーライド可能）
依存関係グラフがサポートするエコシステムに対応

5.3.2 有効化方法

リポジトリの Settings → Security & analysis
Dependabot security updates の横にある Enable をクリック

GitHub Actionsを使用している場合、Dependabotはワークフロー内で使用されている脆弱なActionsも更新します。

5.4 Dependabot バージョンアップデート

スケジュールに基づいて、依存関係を最新バージョンに保つためのプルリクエストを作成します。

5.4.1 特徴

設定ファイル必須：.github/dependabot.yml が必要
スケジュール実行：設定したスケジュールで実行
最新バージョンへの更新：設定に一致する最新バージョンに更新
より広範なエコシステムサポート

5.4.2 設定例

version: 2
updates:
  # npm の依存関係を管理
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    
  # Docker の依存関係を管理
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"
    
  # GitHub Actions の依存関係を管理
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

5.4.3 有効化方法

リポジトリへの書き込み権限を持つユーザーが、.github/dependabot.yml ファイルをリポジトリに追加することで有効化されます。

6. 依存関係レビュー：プルリクエストでの事前チェック

依存関係レビューは、プルリクエストに含まれる依存関係の変更を可視化し、新たな脆弱性の導入を防ぎます。

6.1 依存関係レビューの仕組み

6.2 表示される情報

追加、削除、更新された依存関係
リリース日
依存関係の人気度
既知の脆弱性情報

6.3 利用可能性

パブリックリポジトリ：デフォルトで有効
プライベートリポジトリ：GitHub TeamまたはGitHub Enterprise Cloudで、GitHub Code SecurityまたはGitHub Advanced Securityライセンスが必要

7. Dependency Review Action：ワークフローへの統合

dependency review actionは、GitHub Actions内で依存関係レビューを実行し、強制力を持たせることができます。

7.1 基本的なワークフロー

name: '依存関係レビュー'
on: [pull_request]

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
    - name: 'リポジトリをチェックアウト'
      uses: actions/checkout@v5
    - name: 依存関係レビュー
      uses: actions/dependency-review-action@v4

7.2 カスタマイズ例

7.2.1 重要度レベルでのフィルタリング

- name: 依存関係レビュー
  uses: actions/dependency-review-action@v4
  with:
    # critical レベル以上の脆弱性のみブロック
    fail-on-severity: critical

7.2.2 ライセンスの制限

- name: 依存関係レビュー
  uses: actions/dependency-review-action@v4
  with:
    # 許可するライセンス
    allow-licenses: GPL-3.0, BSD-3-Clause, MIT
    # または、禁止するライセンス
    # deny-licenses: LGPL-2.0, BSD-2-Clause

7.2.3 スコープによるフィルタリング

- name: 依存関係レビュー
  uses: actions/dependency-review-action@v4
  with:
    # development, runtime スコープの脆弱性をブロック
    fail-on-scopes: development, runtime

7.2.4 特定の脆弱性を除外

- name: 依存関係レビュー
  uses: actions/dependency-review-action@v4
  with:
    # 特定のGHSA IDをスキップ
    allow-ghsas: GHSA-abcd-1234-5679, GHSA-efgh-1234-5679

7.3 設定ファイルを使用したカスタマイズ

より複雑な設定の場合、外部設定ファイルを使用できます：

name: '依存関係レビュー'
on: [pull_request]

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
    - name: 'リポジトリをチェックアウト'
      uses: actions/checkout@v5
    - name: 依存関係レビュー
      uses: actions/dependency-review-action@v4
      with:
        # ローカルの設定ファイルを指定
        config-file: './.github/dependency-review-config.yml'
        # または外部リポジトリの設定ファイル
        # config-file: 'organization/config-repo/dependency-review-config.yml@main'
        # external-repo-token: 'ghp_xxxxxxxxxxxx'

設定ファイル（.github/dependency-review-config.yml）の例：

fail-on-severity: critical

allow-licenses:
  - GPL-3.0
  - BSD-3-Clause
  - MIT

deny-licenses:
  - LGPL-2.0
  - BSD-2-Clause

allow-ghsas:
  - GHSA-abcd-1234-5679
  - GHSA-efgh-1234-5679

fail-on-scopes:
  - development
  - runtime

7.4 ベストプラクティス

ブロックリストを優先：許可リストよりも「本当に悪い」依存関係のブロックリストを作成する方が実用的
ライセンスの除外を選択：互換性のあるライセンスの完全なリストを作成するより、互換性のないライセンスを除外する方が実用的
重要度ベースの失敗を選択：セキュリティの必要性と開発者体験のバランスを取る良い方法

8. 組織全体での依存関係レビューの強制

組織全体で依存関係レビューを標準化するには、リポジトリルールセットを使用します。

8.1 リポジトリルールセットとは

リポジトリルールセットは、選択したブランチやタグに対するユーザーの操作を制御するルール設定です。dependency review actionを必須ワークフローとして設定することで、すべてのチェックに合格しない限りプルリクエストをマージできないようにします。

8.2 設定手順

組織のプロフィール写真をクリック → Settings
左サイドバーの Repository → Rulesets
New ruleset ドロップダウンから New branch ruleset を選択
ルールセット名を入力
Enforcement status を Active に設定
オプション：特定のリポジトリをターゲットにする
Rules セクションで Require workflows to pass before merging を選択
Workflow configurations で Add workflow をクリック
dependency review actionが設定されているリポジトリを選択
ブランチとワークフローファイルを選択
Create をクリック

これにより、組織内の対象リポジトリすべてで、dependency review actionが合格しない限りマージができなくなります。

9. SBOM（Software Bill of Materials）：透明性の確保

SBOMは、プロジェクトの依存関係の正式な機械可読インベントリです。SPDX標準フォーマットでエクスポートできます。

9.1 SBOMが提供する価値

透明性：リポジトリが使用する依存関係の透明性を提供
脆弱性の特定：コードベース全体での脆弱性の特定を可能に
ライセンスコンプライアンス：ライセンス、セキュリティ、品質の問題についての洞察
規制対応：米国連邦政府への納入時など、データ保護基準への準拠を支援

9.2 エクスポート方法

9.2.1 UI経由

リポジトリのメインページへ移動
Insights タブをクリック
左サイドバーの Dependency graph をクリック
Dependencies タブの右上にある Export SBOM をクリック

9.2.2 REST API経由

curl -H "Authorization: token YOUR_TOKEN" \
  https://api.github.com/repos/OWNER/REPO/dependency-graph/sbom

9.3 GitHub Actions経由でのSBOM生成

SPDX Dependency Submission Actionを使用した例：

name: SBOM アップロード

on:
  workflow_dispatch:
  push:
    branches: ["main"]

jobs:
  SBOM-upload:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: write

    steps:
    - uses: actions/checkout@v5
    
    - name: SBOM を生成
      run: |
        curl -Lo $RUNNER_TEMP/sbom-tool https://github.com/microsoft/sbom-tool/releases/latest/download/sbom-tool-linux-x64
        chmod +x $RUNNER_TEMP/sbom-tool
        $RUNNER_TEMP/sbom-tool generate -b . -bc . -pn ${{ github.repository }} -pv 1.0.0 -ps 所有者名 -nsb https://sbom.mycompany.com -V Verbose
    
    - uses: actions/upload-artifact@v4
      with:
        name: sbom
        path: _manifest/spdx_2.2
    
    - name: SBOM をアップロード
      uses: advanced-security/spdx-dependency-submission-action@v1
      with:
        filePath: "_manifest/spdx_2.2/"

このワークフローは：

Microsoft SBOM Toolを使用してSPDX 2.2互換のSBOMを生成
生成されたSBOMをアーティファクトとしてアップロード
依存関係サブミッションAPIにSBOMを送信

10. Immutable Releases：リリースの完全性保証

Immutable Releases（不変リリース）は、公開後に変更できないリリースです。サプライチェーン攻撃を防ぐための重要な機能です。

10.1 保護される内容

10.2 防止される攻撃

既存のリリースへの脆弱性やマルウェアの注入
開発者ワークフローを破壊するアセットやタグの変更
リポジトリ復活攻撃（リポジトリを削除後、同名で再作成してタグを再利用）

10.3 有効化方法

10.3.1 リポジトリレベル

リポジトリの Settings へ移動
Releases セクションまでスクロール
Enable release immutability を選択

10.3.2 組織レベル

組織のメインページへ移動
Settings をクリック
サイドバーの Repository ドロップダウンから General を選択
Releases セクションで No policy ドロップダウンから All repositories または Selected repositories を選択
選択したリポジトリの場合、リポジトリを選択

重要: 不変性は将来のリリースにのみ適用されます。既存のリリースは影響を受けません。

10.4 ベストプラクティス

推奨ワークフロー：

リリースをドラフトとして作成
すべての関連アセットをドラフトリリースに添付
ドラフトリリースを公開

このアプローチにより、リリースが不変になる前にすべてのアセットが揃っていることを保証できます。

10.5 リリースの完全性検証

GitHub CLIを使用して、リリースとローカルアーティファクトの完全性を検証できます：

# リリースが存在し、不変であることを確認
gh release verify v1.0.0

# ローカルアーティファクトがリリースアセットと一致することを確認
gh release verify-asset v1.0.0 /path/to/local/artifact.tar.gz

注意: この検証コマンドは、リリースのソースコードzipファイルやtarballには使用できません。これらのアセットはダウンロード要求時にのみ作成されるためです。

11. エンドツーエンドのセキュリティベストプラクティス

サプライチェーンセキュリティは、アカウント、コード、ビルドシステムの3つの層で考える必要があります。

11.1 アカウントのセキュリティ

11.1.1 2要素認証（2FA）の設定

最も重要なのは2FAの有効化です。パスワードだけでは以下のリスクがあります：

推測可能
他のサイトで再利用され、そのサイトが侵害された場合に流出
フィッシングなどのソーシャルエンジニアリング

推奨される2FA方法の優先順位：

パスキー / セキュリティキー（WebAuthn）
- FIDO2ハードウェアセキュリティキー
- Windows Hello、Apple Touch ID等のプラットフォーム認証
- パスワードマネージャー
- フィッシングに対して最も強固（ドメインスコーピングがプロトコルに組み込まれている）
認証アプリ（TOTP）
- Google Authenticator、Authy等
- パスキーより脆弱だがSMSより安全
SMS（非推奨）
- NIST 800-63Bデジタルアイデンティティガイドラインでは推奨されていない
- フィッシングに脆弱

ベストプラクティス：

常に少なくとも2つの第2要素認証情報を登録
リカバリーコードをダウンロード
組織所有者の場合、組織全体で2FAを必須化

11.1.2 SSH鍵の管理

GitHub へのコードプッシュにSSH鍵を使用している場合：

パスフレーズで保護：ディスクドライブに保存されているSSH秘密鍵は、パスフレーズで保護することを推奨
ハードウェアセキュリティキーでの生成：2FAで使用しているのと同じキーを使用可能。ハードウェアから秘密鍵が直接アクセス不可能なため、リモートからの侵害が非常に困難

# ハードウェアセキュリティキーでSSH鍵を生成
ssh-keygen -t ed25519-sk -C "tanaka.taro@example.com"

11.2 コードのセキュリティ

11.2.1 脆弱性管理プログラム

完全な脆弱性管理プログラムには以下が含まれます：

依存関係のインベントリ作成
- 依存関係グラフによる自動生成
- 必要に応じてSBOMエクスポート
脆弱性の検知
- Dependabotアラートによる自動通知
- dependency review actionによるPR時のチェック
リスクの評価
- 重要度スコアの確認
- プロジェクトでの実際の使用状況の評価
- 攻撃の可能性と影響の判断
対応アクションの決定
- すぐに更新が必要か
- 通常のリリースサイクルで対応可能か

11.2.2 シークレットの保護

Secret Scanning：

パブリックリポジトリ：無料で利用可能、パートナープロバイダーに自動通知
プライベートリポジトリ：GitHub Advanced Security必要

GitHubでのシークレット保存：

GitHub Actions用：Actions secrets
Dependabot用：Dependabot secrets設定
Codespaces用：アカウント固有のシークレット

ベストプラクティス：

シークレットをソースコードに含めない
環境変数や暗号化されたシークレット管理システムを使用
定期的にシークレットをローテーション

11.2.3 コードスキャニング

name: コードスキャニング

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
  schedule:
    - cron: '0 0 * * 1'

jobs:
  analyze:
    name: 解析
    runs-on: ubuntu-latest
    permissions:
      actions: read
      contents: read
      security-events: write

    strategy:
      fail-fast: false
      matrix:
        language: [ 'javascript', 'python' ]

    steps:
    - name: リポジトリをチェックアウト
      uses: actions/checkout@v5

    - name: CodeQL を初期化
      uses: github/codeql-action/init@v3
      with:
        languages: ${{ matrix.language }}

    - name: Autobuild
      uses: github/codeql-action/autobuild@v3

    - name: CodeQL 解析を実行
      uses: github/codeql-action/analyze@v3

11.3 ビルドシステムのセキュリティ

11.3.1 GitHub Actionsの活用

GitHub Actionsが提供するセキュリティ機能：

明確で再現可能なビルドステップ
- ワークフロー定義がリポジトリに保存
- バージョン管理された実行環境
実行環境の透明性
- ビルドログの完全な記録
- すべてのステップの可視化
クリーンな環境
- 各ビルドが新しいランナーイメージで開始
- 侵害されたビルドが永続化しない

11.3.2 アーティファクト証明

アーティファクト証明は、ビルドの来歴と完全性を暗号学的に保証します。

name: ビルドと証明

on:
  push:
    branches: [ main ]
  release:
    types: [ created ]

permissions:
  id-token: write
  contents: read
  attestations: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v5
    
    - name: アプリケーションをビルド
      run: |
        npm ci
        npm run build
        
    - name: アーティファクトの証明を生成
      uses: actions/attest-build-provenance@v2
      with:
        subject-path: 'dist/app.tar.gz'

証明には以下が含まれます：

ワークフローへのリンク
リポジトリ、組織、環境、コミットSHA、トリガーイベント
OIDCトークンからのその他の情報

11.3.3 ビルドへの署名

より高度なセキュリティのため、ビルドに署名することを検討してください：

OpenID Connectを使用した認証
GitHub Actions encrypted secretsの使用
自己ホストランナーでのプライベートキー管理

12. トラブルシューティング

12.1 依存関係グラフが期待通りでない場合

12.1.1 確認事項

マニフェストファイルの場所
- 依存関係は10MB未満のマニフェストファイルからのみ処理
- デフォルトで150個までのマニフェストを処理
- ベンダー依存関係ディレクトリ（vendor/, third-party/, externals/等）は無視
変数の使用
- マニフェスト内で変数を使用している場合、静的解析では解決不可
- 依存関係サブミッションAPIの使用を検討
依存関係グラフの再構築
- Dependabot alerts タブから Refresh Dependabot alerts を選択
- 1時間に1回のみトリガー可能

12.2 自動依存関係サブミッションのトラブルシューティング

12.2.1 キャッシュ管理

自己ホストランナーでキャッシュを独自に管理したい場合：

env:
  GH_DEPENDENCY_SUBMISSION_SKIP_CACHE: true

12.2.2 Maven プロジェクト

タイムスタンプが pom.xml の最終変更と一致することを確認
pom.xml を更新するコミットをプッシュすると、新しいビルドがトリガー

12.2.3 Gradle プロジェクト

Actions タブで「Automatic Dependency Submission (Gradle)」を確認
出力にはAPIに送信されたJSONペイロードが含まれる

12.2.4 .NET プロジェクト

component-detectionプロジェクトを使用
.NET 8.x, 9.x, 10.x をサポート
ルートディレクトリに .sln, .csproj, packages.config, .vbproj, .vcxproj, または .fsproj が必要

12.2.5 Python プロジェクト

component-detectionプロジェクトを使用
ルートディレクトリに requirements.txt が必要
.python-version ファイルでPythonバージョンを指定する必要あり
プライベートパッケージは現在サポートされていない

13. まとめ

GitHubのサプライチェーンセキュリティ機能は、依存関係グラフを中心とした統合されたエコシステムを形成しています。

13.1 主要なポイント

階層的なアプローチ
- 依存関係グラフがすべての基盤
- Dependabot、dependency reviewがその上に構築
自動化の重視
- 手動監視を最小化
- 継続的な保護を提供
開発ワークフローへの統合
- GitHub Actionsとの深い統合
- CI/CDパイプライン内でのセキュリティチェック
組織レベルの制御
- リポジトリルールセットによる標準化
- 一貫したセキュリティポリシーの適用
透明性と検証可能性
- SBOMエクスポート
- Immutable releases
- アーティファクト証明

13.2 実装の推奨順序

この順序で実装することで、段階的にセキュリティを強化できます。

13.3 継続的な改善

サプライチェーンセキュリティは、一度設定したら終わりではありません。継続的な改善のために：

定期的にDependabotアラートを確認
新しいエコシステムサポートを活用
セキュリティポリシーを定期的に見直し
チームでのセキュリティ意識を向上

GitHubのサプライチェーンセキュリティ機能を活用することで、安全で信頼性の高いソフトウェア開発が実現できます。まずは依存関係グラフの有効化から始めてみてください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up