ソフトウェアサプライチェーン攻撃にどう対処する？GitLabを活用した対策5選
- 執筆者
-
aslead編集部こんにちは。aslead編集部です。
最新ソフトウェア開発のトレンドから、AI・DXツールの効果的な活用法、企業のITガバナンスの強化、業務効率化やDX化を成功に導くソリューションまで、幅広い記事を提供しています。
企業が直面する課題の解決策として効率的なツールの活用方法を探求し、生産性の向上に繋がる実践的な情報をお届けすることを目指します。
なぜソフトウェアサプライチェーンが狙われるのか
近年、ソフトウェアサプライチェーン攻撃による被害が急増しています。npmやPyPIのパッケージ侵害、Trivyの侵害事例など、情報セキュリティを専門としない方でも関連ニュースを目にする機会が増えているのではないでしょうか。
現代のソフトウェア開発において、すべてのコードを自社でゼロから書き上げるケースは少なく、多数のOSSやサードパーティ製ライブラリ、外部ツールを組み合わせながらシステムを構築するのが一般的です。さらに、それらのライブラリ自体もまた別のコンポーネントに依存しており、ソフトウェアは目に見えない多層の依存関係の上に成り立っています。
ソフトウェアサプライチェーン攻撃は、こうした「信頼の連鎖」を逆手に取るサイバー攻撃です。上流のパッケージや開発基盤の一部が侵害されると、その影響が下流の開発環境や本番システム、さらには顧客環境にまで波及するおそれがあります。なかでも、近年はバージョン管理システムやCI/CDパイプラインといった開発の中核を狙う攻撃が増えており、多くの企業にとって見過ごせないリスクとなっています。
そこで、本記事ではDevSecOpsプラットフォームとして広く利用されている「GitLab」に焦点を当て、ソフトウェアサプライチェーンを守るために実践したい5つの対策をご紹介します。現場ですぐに着手しやすい対策から、組織全体に適用すべき統制まで、順を追って整理します。
※本記事は2026年6月時点の情報にもとづいています。
まず理解しておきたい、サプライチェーン攻撃の流れ
ソフトウェアサプライチェーン攻撃にはさまざまな切り口があります。その中でも、代表的なケースとしてバージョン管理システムやCI/CDパイプラインを狙う攻撃を取り上げると、大きく4つのフェーズで整理できます。
①外部パッケージやOSSが侵害される
攻撃のスタート地点となるのは、自社で利用しているOSSや外部パッケージです。攻撃者は、OSSメンテナーの認証情報を盗んで不正なコードを仕込んだり、著名なパッケージとよく似た名前で悪意あるパッケージを公開するなどして、汚染されたパッケージを広く流通させます。
②汚染されたコンポーネントが自社環境に入り込む
開発者が汚染されたパッケージに気づかずにインストールやアップデートすると、悪意あるコンポーネントがローカル環境やビルド環境に取り込まれます。外部での侵害が内部環境へ連鎖することで、サプライチェーン攻撃が成立します。
③パイプラインやビルド処理で不正コードが実行される
悪意あるパッケージが取り込まれる際、例えばnpm install実行時に連動して悪意のあるスクリプトが動き出し、不正なコードが実行されます。さらに、攻撃者はCI/CDの設定やジョブ実行の仕組みを悪用し、パイプライン上で任意のコードを実行できる足場を作ろうとします。強力な権限を持ち、自動化の基盤であるバージョン管理システムやCI/CDが狙われる最大の理由がここにあります。
④機密情報の窃取・成果物の改ざんなどの被害に発展する
一度パイプライン上で実行権限を握られてしまうと、攻撃者は思いのままに活動を広げます。例えば、マルウェア本体のダウンロード、インフラの認証情報や機密コードの流出、リリース直前の成果物へのバックドア混入など、被害は深刻化しやすくなります。結果として、自社だけでなく、そのシステムを利用する顧客や取引先（サプライチェーンの下流）にも被害が及んでしまう、甚大なリスクへと発展します。
GitLabを活用した対策
このように侵入経路が複雑なサプライチェーン攻撃を防ぐためには、開発ライフサイクル全体に複数の防御策を組み込み、侵入・実行・拡散の各段階で被害を食い止めることが重要です。ここからは、その考え方にもとづいてGitLabで実践しやすい5つの対策をご紹介します。
１. 機密情報をリポジトリに含めない
最初に着手したいのは、認証情報や秘密情報をソースコードに残さない状態にすることです。APIキーやデータベースなどのパスワードがリポジトリに含まれていると、万一リポジトリへ不正アクセスされた際に、インフラ全体へ被害が波及するおそれがあるためです。
とはいえ、ルールや注意喚起だけで開発者の「うっかりミス」を完全になくすのは現実的ではありません。そこで有効なのが、GitLabで機械的に機密情報を検知・遮断する仕組み作りです。
- Push Rules（プッシュルール）：コードをPushする際のルールをあらかじめ定義し、.envや.pemといった特定のファイルをPushできないように制御します。なお、global/group push rulesは新規プロジェクト向けのテンプレートとして機能しますが、既存プロジェクトへ自動反映されるわけではないため、適用範囲の確認が必要です。
- Secret Push Protection（シークレットプッシュ保護）：開発者がPushしたタイミングでスキャンを実行し、AWSアクセスキーなどのシークレットが見つかると、原則としてそのPushをブロックします。やむを得ず回避した場合でも、監査イベント（Premium/Ultimateプランで利用可）に記録されるため、責任追跡性を確保しやすくなります。
- GitLab Secrets Manager（シークレット管理）：シークレットをGitLab上で暗号化して安全に保管し、必要なパイプラインにのみ読み込ませる機能です。外部ツールに頼りすぎず、開発フローに近い場所で一貫して管理したい場合に有効です（GitLab 19.0ではPublic Beta版※1として提供）。
２. 使用しているコンポーネントを把握する
「自社のシステムがどのコンポーネントで構成されているか」を正確に把握することは、サプライチェーンを守るための大前提です。経済産業省の資料でも推奨されているように、近年はSBOM（Software Bill of Materials：ソフトウェア部品表）を整備し、ソフトウェアサプライチェーンを把握するのがスタンダードになっています。
- Dependency Scanning（依存関係スキャン）：リポジトリ内の依存関係を自動で解析し、SBOMを生成して一覧表示できます。自社で利用しているOSSやサードパーティ製ライブラリを継続的に把握する第一歩として有効です。
- Continuous Vulnerability Scanning（継続的脆弱性スキャン）：デフォルトブランチでDependency Scanningを実行し、SBOMを生成しておくことで、新たに脆弱性情報が公開された際にSBOMと照合させることができます。ゼロデイ脆弱性のように後からリスクが顕在化するケースでは特に有効で、自社への影響を継続的に照合しやすくなります。一方で、依存関係が更新された場合はSBOMも更新する必要があり、脆弱性の解消状況を正しく把握するには最新のスキャン結果が求められます。そのため、スケジュール実行やrules句と組み合わせてパイプラインを定期実行する運用が効果的です。
以下ブログでは、GitLabで生成できるSBOMの概要と生成の流れをご紹介しています。
３. 悪意のあるコードの混入を防ぐ
バージョン管理システムは開発成果物の信頼性を支える基盤であるため、ここに悪意ある変更が入り込むと、コード改ざんにとどまらずCI/CDの設定変更や不正ジョブの実行にもつながります。このリスクに対しては、「誰が変更できるか」「どの変更に承認が必要か」を明確にし、重要なブランチやファイルを保護することが重要です。
- Protected Branches（ブランチ保護）：mainやreleaseなどの重要なブランチに対して、pushやmergeを実行できるユーザーを制限できます。未承認の変更が本流のブランチへ入り込むリスクを抑える、基本的な統制機能です。
- Code Owners（コードオーナー）：重要なディレクトリやファイルに責任者を割り当て、その人のレビューと承認がなければ変更できないようにします。とくにCI/CDの設定ファイルやセキュリティ関連ディレクトリなど、影響範囲の大きい箇所に対して設定するのが有効です。なお、Protected Branchに対するDirect Push権限を持つユーザーは、Merge RequestとCode Ownerの承認フローをスキップできるため、権限管理を厳格に行うことが重要です。
- Multiple Approval Rules（複数承認の必須化）：Merge Requestに対して複数メンバーの承認を必須にすることで、単一アカウントの侵害で変更がそのまま通ってしまうリスクを下げられます。これにより、単一アカウントが乗っ取られた際の対策や、レビューの相互牽制を仕組み化できるなどのメリットがあります。
４. セキュリティポリシーを組織全体へ適用する
企業規模が大きくなり、管理するプロジェクトが増えるほど、各チームにルールの徹底を喚起するだけでは限界が生じます。また、「このプロジェクトだけセキュリティ設定が漏れていた」という単一障害点が、組織全体の致命傷になるケースも珍しくありません。そこで必要になるのが、プロジェクトの枠を超えて、グループやインスタンスのレベルでセキュリティ設定を一貫して適用する仕組みです。
- Scan Execution Policy（スキャン実行ポリシー）：SAST（静的解析）などの各種セキュリティスキャンを、管理者が定めた条件・タイミングで各プロジェクトへ強制実行できます。特に、GitLabが提供する標準スキャンを素早く組織内に展開したい場合に適しています。
- Pipeline Execution Policy（パイプライン実行ポリシー）：各プロジェクトで独自に作ったCI/CDパイプラインに対して、コンプライアンスチェックや署名検証など、管理側で定義したジョブを強制的に差し込めます。独自のジョブやサードパーティ製ツールを組織全体に適用したい場合は、こちらの利用が有効です。
これらのポリシーをもとに見つかった脆弱性は、セキュリティダッシュボード（Ultimateプランで利用可）でプロジェクトを横断して確認することができます。
GitLab社の公式ブログでは、実際のパイプライン実行ポリシーの活用例が紹介されています。
５. AIを活用して対策のスピードと精度を高める
脆弱性対応やセキュリティレビューの負荷が高まるなか、人手だけで対応し続けるのは難しくなっています。検出件数が多いほど、脆弱性の確認、優先度付け、修正提案などの各工程がボトルネックになりやすいためです。
こうした場面では、防御側にもAIを活用して対策する「AI for Security」として、AIを活用してセキュリティ運用のスピードと精度を高めるアプローチが有効です。GitLab Duoは、DevSecOpsライフサイクル全体を支援する仕組みとして、こうした用途にも活用できます。
- Security Analyst Agent（セキュリティ分析エージェント）：セキュリティ対策に特化したエージェントで、脆弱性の評価や優先度付け、修正に活用できます。
- SAST false positive detection（SASTの誤検出判定）：GitLabがサポートするSASTアナライザーで検出されたCritical/Highの脆弱性について、誤検出（False-Positive）の可能性をAIで判定し、優先的に取り組むべき脆弱性の抽出を支援します。
- Agentic SAST Vulnerability Resolution（エージェント型のSAST脆弱性解決）：誤検出ではないと判断されたCritical/Highの脆弱性を対象に、AIが修正案を含むMerge Requestの作成を支援します。
以下ブログでは、実際にGitLab Duoで脆弱性を修正した事例をご紹介しています。
GitLab Duo Agent Platform活用による脆弱性対応フローの効率化
まとめ
本記事では、深刻化するソフトウェアサプライチェーン攻撃から自社を守るための、GitLabを活用した5つの対策をご紹介しました。いずれの機能も、SaaS版（GitLab.com）およびオンプレミス版（Self-Managed）でご利用いただけます。
| 対策 | GitLabの機能 | プラン | ||
|---|---|---|---|---|
| Free | Premium | Ultimate | ||
| ①機密情報を リポジトリに 含めない |
Push Rules （プッシュルール） |
〇 | 〇 | |
| Secret Push Protection （シークレットプッシュ保護） |
〇 | |||
| GitLab Secrets Manager （シークレット管理） |
〇※1 | 〇※1 | ||
| ②使用している コンポーネントを 把握する |
Dependency Scanning （依存関係スキャン） |
〇 | ||
| Continuous Vulnerability Scanning （継続的脆弱性スキャン） |
〇 | |||
| ③悪意のある コードの混入を 防ぐ |
Protected Branches （ブランチ保護） |
〇 | 〇 | 〇 |
| Code Owners （コードオーナー） |
〇 | 〇 | ||
| Multiple Approval Rules （複数承認の必須化） |
〇 | 〇 | ||
| ④セキュリティ ポリシーを組織 全体へ適用する |
Scan Execution Policy （スキャン実行ポリシー） |
〇 | ||
| Pipeline Execution Policy （パイプライン実行ポリシー） |
〇 | |||
| ⑤AIを活用して 対策のスピードと精度を高める |
Security Analyst Agent （セキュリティ分析エージェント） |
〇 | ||
| SAST false positive detection （SASTの誤検出判定） |
〇 | |||
| Agentic SAST Vulnerability Resolution （エージェント型のSAST脆弱性解決） |
〇 | |||
※1：GitLab 19.0ではPublic Beta版の機能です。ベータ版サポートポリシーに従うため、本番環境での利用には適していない可能性があります。
重要なのは「この対策をしていれば100%安全になる」という銀の弾丸は存在しないということです。サイバー攻撃の戦術は絶えず進化しており、単一の防御策に頼っていては、いずれ突破されるリスクが拭えません。そのため、今回ご紹介したような複数のセキュリティ対策を組み合わせ、一つが破られても次の壁で防ぐ「多層防御」を開発プロセス全体に組み込むことが重要です。
GitLabは、コード管理、CI/CD、セキュリティスキャン、ポリシー適用、AI活用までをひとつのプラットフォーム上で連携させやすい点が特長です。サプライチェーン対策を部分最適ではなく、開発プロセス全体の設計として見直したい企業にとって、有力な選択肢のひとつになるでしょう。
株式会社野村総合研究所（NRI）は、GitLab社と販売代理店契約を締結しており、中でも優れた顧客価値を提供した実績を持つパートナーだけに与えられる「GitLab Professional Services Partners」に認定されています。GitLabを活用した業務コンサルティングから製品導入、QAサポートに至るまで、一貫したトータルサポートをご提供しております。
GitLabの導入に関するご相談や費用のお問い合わせ、GitLab無料トライアルの申し込みについては、下記のお問い合わせフォームよりお気軽にお問い合わせください。
