Software Supply Chain全域に広がる「ビルドパイプライン攻撃」
背景と概要
現代のソフトウェア開発は、ゼロからコードを書くのではなく、外部のオープンソースライブラリ（OSS）を組み込み、CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインを通じて自動的にテスト・ビルド・デプロイする運用が標準となっています。
しかし、製品そのものの脆弱性を突くことが難しくなった結果、攻撃者のターゲットは「ソフトウェアの作成現場（サプライチェーン）」へとシフトしました。ソースコードの作成から配信に至るプロセス全体を標的とする「ソフトウェアサプライチェーン攻撃」は、一企業の被害にとどまらず、そのソフトウェアを利用する世界中の顧客企業へ連鎖的な被害をもたらすため、深刻な国際課題となっています。
ビルドパイプライン攻撃の主な侵入・悪用ルート
ソフトウェアサプライチェーン攻撃は、開発工程のどの段階でも発生する可能性があります。
- 依存ライブラリ（OSS）への毒入れ（Dependency Confusion / Typosquatting）
開発者が利用するnpmやPyPIなどの公開リポジトリにおいて、有名なライブラリと一文字違いの悪質パッケージ（Typosquatting）を公開したり、社内限定パッケージと同名の悪質コードをパブリック側に配置して誤って取得させたり（Dependency Confusion）します。
- CI/CDサーバー・開発環境の侵害（ビルド環境の汚染）
GitHub Actions、GitLab CI、Jenkinsなどのビルドサーバーのアクセス権限を奪い、ソースコード自体は変更せずに「ビルド（コンパイル）処理の最中」だけ悪意あるコードをバイナリに注入する高度な手口（SolarWinds型攻撃）です。
- コード署名鍵の強奪
正規のソフトウェアとして配布するために必要な「デジタルコード署名鍵」を開発企業から盗み出し、マルウェアを仕込んだアップデートプログラムに正規の署名を施して配信します。
サプライチェーン侵害が引き起こすビジネス影響
開発元企業にとっては「自社製品がマルウェアの配布元になってしまう」という、企業の存在価値を揺るがす信用失墜につながります。また、購入企業側にとっては、信頼して導入した正規アップデートを通じて社内網へバックドアを仕掛けられるため、従来の境界防衛では防ぎようがないという構造的弱点が存在します。
DevSecOpsとSLSAフレームワークに基づく対策
開発プロセスの透明性と改ざん防止（完全性）を担保する取り組みが進められています。
- SLSA（Supply-chain Levels for Software Artifacts）の導入
Google等が提唱するビルドプロセスの安全基準「SLSA」を参考に、ソースコードの変更からバイナリ生成までの全工程で「誰がいつ変更したか」の追跡可能性（トレーサビリティ）を担保します。
- SBOM（ソフトウェア部品表）の作成と自動脆弱性スキャン
製品に含まれるすべてのOSSコンポーネントとバージョンを一覧化した「SBOM」を自動生成し、既知の脆弱性や不正なライブラリが混入していないかをCI/CDパイプライン上でチェックします。
- ビルド環境の分離とシークレット（鍵）管理の徹底
ビルドサーバー上の環境変数の保護を徹底し、コード署名鍵はHSM（ハードウェアセキュリティモジュール）などの専用環境で厳重に管理・アクセス制御を行います。