はじめに
みなさんこんにちは。エーピーコミュニケーションズ ACS事業部 亀崎です。
少し前にSBOMやGitHub Advanced Securityで実現する ソフトウェアサプライチェーンセキュリティといったものを 紹介させていただきました。そこでSLSAという言葉が登場してきたかと思います。
では、SLSAとはどういったものなのでしょうか。今回はその内容をご紹介し、 あらためてGitHub Advanced SecurityとSLSAの関係について整理 してみたいと思います。
なお、本ブログはNotebookLMにてSLSAについて情報収集しまとめたものをベースに、 私自身が編集・追記したものです。
SLSAの概要
SLSAとは
SLSA（Supply-chain Levels for Software Artifacts、サルサと読みます）は、 ソフトウェア・サプライチェーンの完全性を保護し、改ざんを防止するための セキュリティ・フレームワークです
SLSAの主な目的は、ソフトウェアが「意図した通りのソースコードから作られ、 ビルドプロセス中に何者にも改ざんされていないこと」を客観的に証明する 仕組み（検証可能な信頼）を構築することにあります。
SLSAの脅威モデル
SLSAの脅威モデルは、ソフトウェアが作成されてから消費されるまでの パイプライン全体をカバーしており、脅威を(A)から(I)のカテゴリーに分類して、 それぞれに対する緩和策を定義しています。
緩和策については、引用元のページを ご確認ください。
１） ソースコードに関する脅威（A～C）
ソースコードの完全性を損ない、開発者の意図しない変更が混入するリスクを対象とします。
（A）生産者による不正: 生産者が意図的に悪意あるコードを作成する脅威です。
(B) ソースの改ざん: レビューを回避してコードを提出したり、 履歴を書き換えたりする脅威です。
（C）ソース管理プラットフォームの侵害: 管理者権限の悪用やインフラの侵害による 改ざんです。
２）ビルドプロセスに関する脅威 (D〜G)
ソースコード自体は正しくても、ビルドや配布の過程で悪意ある挙動が注入される リスクを対象とします。
（D）外部ビルドパラメータの操作: 非公式のフォークや、意図しない パラメータ（デバッグ設定など）を使用してビルドさせる脅威です。
（E）ビルドプロセスの侵害: ビルドサーバーに侵入し、コンパイル中に コードを差し替えたり、プロバナンス（由来情報）を偽造したりする脅威です
（F, G）配布中の改ざん: ビルド後の成果物をリポジトリへのアップロード中、 あるいは消費者へ届くまでの間に差し替える脅威です。
３） 使用および依存関係に関する脅威 (H〜I)
消費者が誤ったパッケージを選択したり、上流のライブラリが侵害されていたりするリスクです。
（H）パッケージ選択の誤り: 依存関係の混乱（Dependency Confusion）や タイポスクワッティングにより、利用しているライブラリと同じ名前の悪意あるライブラリを 公開リポジトリに配置し、誤ってインストールさせる脅威です。
(I) 認証情報: 攻撃者がデフォルトの認証情報を利用して秘密データにアクセスします。 （サプライチェーン上の脅威でありますが、SLSAのスコープ外となっています）
(上記以外) 依存関係の脅威: 使用しているサードパーティ製のライブラリ自体が 侵害されているケースです。
引用元： https://slsa.dev/spec/v1.2/threats-overview
これだけの箇所で脅威があると検討すべきことも多岐にわたります。 これらの脅威を領域ごとに整理して段階的な対策（レベル）を定めたものが次に紹介する SLSAの主な構成要素になります。
SLSAの主な構成要素
トラック（Tracks）とレベル（Levels）
SLSAは、サプライチェーンの特定の領域に焦点を当てた「トラック(Tracks)」と、 セキュリティの堅牢度を示す「レベル(Levels)」で構成されています。
トラック(Tracks)は ソフトウェアサプライチェーンの特定の領域に焦点を当て、 そのセキュリティ成熟度を段階的に評価するためのモジュール式の区分です。
レベル(Levels)は、ソフトウェアサプライチェーンのセキュリティの堅牢度を示す 共通言語として機能します。 レベルが上がるにつれて、改ざん防止のためのより厳格なセキュリティ対策と、 ソフトウェアの出自を証明する「プロバナンス（由来情報）」の信頼性が 求められるようになります。
ビルドトラック (Build Track)
現在もっとも採用されているトラックがビルドトラックです。
ビルドプロセス自体の信頼性と、生成される成果物の完全性を保証することを目的としています。
ソフトウェアが「意図したソースコードから正しくビルドされ、改ざんされていないこと」を 証明します。これにはビルドプラットフォームによるプロバナンス（由来情報）の自動生成と署名を 要件とします。
ソーストラック(Source Track)
2025年にリリースされたSLSA v1.2で正式に導入された、ソースコード管理（SCM）の 健全性に焦点を当てたトラックです。
ソースコードが「作成者の意図を正しく反映しており、リポジトリ管理段階で 不正に変更されていないこと」を保証します。これには変更履歴の保持、権限管理を行い、 最高レベルの場合には複数人による承認が必要です。
依存関係トラック(Dependency Track)
執筆時点（2026年1月10日）ではドラフトとなっているトラックで、サードパーティ製の ライブラリやオープンソースコンポーネントなどの外部依存関係から生じるリスクを管理します。
外部から取り込むコンポーネントの可視化とリスク評価を目的とし、 SBOM（ソフトウェア部品表）に よるインベントリ作成、脆弱性のトリアージ、依存関係のミラーリング（内部取り込み）などを 行います。
ビルド環境トラック(Build Environment Track)
執筆時点（2026年1月10日）ではドラフトとなっているトラックで、ビルドが実行される基盤となる コンピューティング環境（インフラ）の整合性を保証します。
ビルド環境での OS、ハイパーバイザー、ハードウェアレベルでの改ざん検知を行います。 署名済みビルドイメージの使用、および最高レベルではコンフィデンシャル・コンピューティングなどの 「ハードウェアによる構成証明」が求められます。
トラックの重要な性質
独立した評価
各トラックのレベルは独立しており、例えば「ビルドはレベル3だが、ソースはレベル1」 といった評価が可能です。
段階的な改善
組織はビジネスニーズやリスクに応じて、特定のトラックのレベルを一つずつ上げていく 戦略的なロードマップを描けます。
共通言語
供給者と消費者の間で「どの領域のセキュリティが、どの程度確保されているか」を 明確に共有するための共通の指標となります。
プロバナンス
さきほどビルドトラックのところで ソフトウェアが「意図したソースコードから正しくビルドされ、改ざんされていないこと」を 証明するためにプロバナンス（由来情報）を自動生成すると説明しました。
では、プロバナンスとはどういったものでしょうか。 プロバナンス（Provenance）とは、成果物（Software Artifact）が 「いつ、どこで、誰によって、どのようなプロセスで作成されたか」を詳細に記述したメタデータのことです。 これはソフトウェアの「出自」や「由来」を証明するデジタルな記録であり、 サプライチェーンの透明性と完全性を担保する基盤となります
プロバナンスに含まれる主な情報は以下の通りです。
- ソースコードの情報: 使用されたソースリポジトリ、ブランチ、および特定のコミットハッシュ（Git SHA）。
- ビルドプロセスの詳細: ビルドを実行したプラットフォームの識別子、実行された具体的なビルドコマンド、環境変数、およびビルドの開始・終了時刻。
- 依存関係: ビルド中に入力として使用されたすべてのサードパーティ製ライブラリやコンポーネントのリスト。
- 成果物の識別: 生成された成果物（Artifacts: ビルドによって生成された実行ファイルやパッケージ）の暗号学的ハッシュ値（ダイジェスト）
プロバナンスは単に『作る』だけでは不十分です。利用者がその内容を 『正しい設定（ポリシー）』と比較して検証することで、初めて その成果物が安全であると証明されます。 加えて Sigstore などのツールを 活用することで、この署名と検証のプロセスを自動化し、信頼性の高いサプライチェーンを 構築することが可能です
評価方法
各トラックのドキュメントに評価すべき内容とそのレベルが記載されています。 それらの内容を確認することで評価が実行できます。
実現方法
SLSAは『何を満たすべきか』を定義する指針（フレームワーク）であり、 特定のツールを指すものではありません。実際には、既存の 開発プラットフォームを組み合わせて要件を満たしていくことになります。
ここではGitHub Advanced Securityにおける実現についてみていきたいと 思います。
GitHub Advanced Securityによる対応
GitHub Advanced Security（GHAS）とSLSAの関係は、 「GHASが提供するセキュリティ機能が、SLSAが定義する各トラック（Build, Source, Dependency）の要件を満たすための具体的な手段（ツール群）として機能する」 という相補的な関係にあります。
具体的には、以下の3つの観点で密接に関連しています。
1. ビルド・トラックにおける「検証可能な信頼」の実現
GitHub Actionsは、SLSAのビルド・トラックにおいてレベル3を 達成できるプラットフォームとして位置づけられています。
- プロバナンス: GitHub Actionsは、ビルド実行時に自動署名する仕組みを提供しています。
- 隔離された環境: 各ビルドは隔離された仮想マシン上で実行され、 ビルド後に破棄されるため、SLSAレベル3の主要要件である「ビルド環境の隔離」を満たします。
2. ソース・トラックにおける整合性の確保
2025年に導入されたSLSA ソース・トラック（Source Track）の要件は、 GHASの主要機能と強く合致しています。
- ソースの完全性: GHASに含まれるコードスキャン（CodeQL）シークレットスキャンは、 ソースコードの脆弱性や機密情報の漏洩を未然に防ぎ、リポジトリの健全性を保ちます。
- 変更管理の強制: GitHubのブランチ保護ルールや、GHASによる自動化された セキュリティチェックは、SLSAレベル4で求められる「2人によるレビュー」や 「管理プロセスへの準拠」を技術的に強制する役割を果たします。
3. 依存関係トラックと透明性の向上
SLSAの依存関係トラック（Dependency Track）は、外部コンポーネントの リスク管理に焦点を当てており、ここでもGHASの機能が活用されます。
- SBOMの生成と管理: GitHubは、ビルドプロセスの一環としてSBOM（ソフトウェア部品表）を 自動生成する機能を提供しており、これは依存関係のインベントリを作成するというSLSAの 基本要件（レベル1）に直結します。
- 脆弱性検知: Dependabotなどの機能は、依存関係に含まれる既知の脆弱性を 継続的にスキャンし、トリアージを支援することで、SLSAの依存関係レベル2以上の要件を サポートします。
結論としての関係性：
GitHubにとってSLSAは、どのようなセキュリティ機能を提供すべきかを決定するための 「ロードマップ」や「指針」として機能しています。一方で利用者にとっては、 GHASを適切に設定して活用することが、SLSAの各レベルへの準拠を証明し、 サプライチェーンの安全性を客観的に実証するための最短ルートとなります。
まとめ
いかがだったでしょうか。少しでもSLSAが理解できましたでしょうか。 またGitHubがその中でどのように位置づけられるのかもご理解いただけましたでしょうか。
もちろん実際にはGitHubだけではなく、その他のツールなども活用してより高いレベルの ソフトウェアサプライチェーンセキュリティを実現することになると思います。
今回の内容やSLSAの評価などを参考に皆さんもご自身の環境について見直してみてはいかがでしょうか。
エーピーコミュニケーションズでは、GitHubを活用したDevOps導入・定着支援、およびGitHub Advanced Securityの導入コンサルティングを行っております。 「設定のベストプラクティスが知りたい」「組織全体への展開をサポートしてほしい」といったご要望に、経験豊富なエンジニアがお応えします。
[https://www.ap-com.co.jp/cloudnative/devops_introduction-for_github/:embed:cite]
セキュリティを「開発のブレーキ」ではなく「加速装置」へ。ぜひ私たちにお手伝いさせてください。
