npm install を実行したり GitHub Actions を動かすとき、依存関係を辿ると何百ものパッケージと、それを書いた多くの開発者のコードを信頼して使うことになります。
でも、その中で何が起きているかまで把握しているでしょうか。
最近では、npm に不正なパッケージが紛れ込んだり、RubyGems でメンテナの権限が突然変更されたりと、普段は意識されにくい部分での問題も増えています。
本記事では、ソフトウェアサプライチェーンのリスクを、初心者にも理解しやすい形で整理します。
ソフトウェアサプライチェーンとは？
例えば、スーパーに並ぶ商品は、原材料の調達、生産、流通という流れを経て店頭で販売されます。
これが「サプライチェーン（供給の連鎖）」です。
ソフトウェアも同じで、コードを書き、ビルドし、パッケージ化し、配布する、のようにユーザーの手に届くまでに、いくつもの工程があります。
この流れが「ソフトウェアサプライチェーン」です。
ソフトウェアがユーザーに届くまでには、多くの仕組み・ツール・人が関わっています。
ソースコードやライブラリ、CI/CD、コンテナ、クラウド環境など、すべてがサプライチェーンの一部です。
ビルドの段階では、外部ライブラリが自動的に取り込まれます。その依存関係が、さらに別のライブラリへとつながっていることもあります。
つまり、私たちが書くコードの裏には、数多くの「他人のコード」が連鎖的に組み込まれています。
どこにリスクがあるのか？
サプライチェーンに潜むリスクは複雑ですが、大きく4つに分けて考えると理解しやすくなります。ここでは以下の観点から整理していきます。
- 人・組織：OSSメンテナ、開発者、CI/CD運用チーム、レジストリ管理団体
- コードと依存関係：自分のコード、依存ライブラリ、ビルド成果物
- インフラ：レジストリ、CI/CD環境、配布サーバや CDN
- 鍵と証明：Secrets、署名鍵、SBOM やプロベナンス情報
まず、全体像を表で整理します。
| 観点 | 代表的な対象 | 主なリスク | 有効な対策/視点 | 例 |
|---|---|---|---|---|
| 人・組織 | メンテナ/開発者、運用チーム、レジストリ運営 | アカウント乗っ取り、ガバナンス不備 | 2FA/鍵管理、責任と承認フローの明確化 | Shai-Hulud（npm） |
| コードと依存関係 | 自作コード、依存ライブラリ、ビルド成果物 | 依存の連鎖、改ざん/悪意挿入 | SCA、署名付きリリース、依存ピン留め | left-pad、Log4j |
| インフラ | CI/CD、レジストリ、CDN | パイプライン侵害、配布経路改ざん | 最小権限、署名検証、監査ログ | 不正ジョブによるSecrets流出 |
| 鍵と証明 | APIトークン、署名鍵、証明書、SBOM/プロベナンス | 秘密情報漏洩、署名鍵悪用、透明性欠如 | キー管理/ローテーション、Sigstore、SLSA、SBOM | 署名なりすまし/影響範囲不明 |
それぞれの観点から見るリスクと対策
それぞれ具体的に見ていきます。対策は、すぐに始められる基本的なものに絞っています。
1. 人・組織
人に依存する部分には、技術だけでは防げないリスクがあります。
-
アカウント乗っ取り
メンテナーや開発者のアカウントが奪われると、不正コードが「正規の権限」で公開されます。npm の Shai-Hulud 事件はその一例です。
-
ガバナンスの不透明性
誰が最終承認者か明確でない、あるいは権限が突然変更されると、利用者は安心して依存できません。RubyGems の権限変更はその一例です。
<すぐできる対策>
- GitHub、npm などのアカウントで2FAを有効化
- 不要になったアクセストークンは削除する
- リポジトリやパッケージの管理者が誰か確認
- 必要最小限の権限だけを与える
- 定期的に権限を見直す
2. コードと依存関係
自分のコードや依存ライブラリに脆弱性や不正が潜む可能性があります。そこに問題があれば、プロダクト全体に波及します。
-
依存の連鎖
一見小さなライブラリでも、多くのプロジェクトがその上に成り立っています。削除や改ざんがあれば、世界中で一斉に不具合や脆弱性が広がります。
2016年の left-pad 削除事件や、2021年の Log4j 脆弱性がその代表例です。
・left-pad 削除：https://news.mynavi.jp/techplus/article/svalley-655/
・Log4j 脆弱性：https://www.jpcert.or.jp/newsflash/2021122401.html
-
改ざん・悪意ある挿入
パッケージにマルウェアが混入する事件も数多く起きています。正規ライブラリを使っているつもりでも、危険なコードを組み込んでしまう可能性があります。
<すぐできる対策>
-
npm listやnpm auditで依存関係と脆弱性を確認 - GitHub の Dependency graph や Dependabot を活用
- どのライブラリが何に依存しているか、定期的にチェック
3. インフラ
ビルドや配布の基盤そのものが攻撃対象になります。ここが侵害されると、「公式レジストリから入手したはずのソフトウェア」がすでに改ざんされている、という状況になります。
-
CI/CD の侵害
GitHub Actions や Jenkins に不正ジョブを仕込まれ、Secrets を外部に送信される事例があります。攻撃者にとっては、開発者の認証情報や署名鍵を奪う効率的な手口となります。
-
配布経路の改ざん
レジストリや CDN が侵害されれば、利用者は「正規URLから偽物を入手」してしまいます。ユーザー側で防ぐのは困難です。
<すぐできる対策>
- GitHub Actions の permissions を明示的に設定
- Secrets は必要なワークフローだけに公開
- サードパーティのアクションは信頼できるものだけを使う
4. 鍵と証明
ソフトウェアの信頼性を保証する仕組みそのものが破られるリスクです。ここが崩れると、利用者は偽物を正規のものとして受け入れてしまいます。
-
Secretsやトークンの漏洩
一度漏れれば、攻撃者は正規の権限で公開や配布を行えます。npm が 2FA を必須化したり、長期トークンを廃止したのはこのリスクに対応するためです。
-
署名鍵の悪用
署名があっても、鍵が盗まれていれば意味がありません。ソフトウェアの「作成者を保証する仕組み」そのものが攻撃対象になります。
-
透明性の欠如
SBOM（ソフトウェア部品表）やビルドのプロベナンス情報がなければ、脆弱性が発覚しても「どこに影響があるのか」を判断できません。その結果、対応が遅れたり、不要な混乱を招く可能性があります。
<すぐできる対策>
- Secrets をコードに直接書かない
- 不要になったトークンは削除する
- アクセス権が変わったら（退職、異動など）トークンを更新
- 定期的に Secrets の一覧を見直す
より実用的な対策
ここまでリスクと、すぐにできる対策を見てきましたが、実際の設定を行うには以下の記事が参考になります。具体的な設定手順、注意点などがまとまっています。
本記事で説明した「どこにリスクが潜むのか」という理解が、これらの記事を読む際や実際に設定を行う際に、少しでも役立てば幸いです。
まとめ
本記事では、ソフトウェアサプライチェーンのリスクを整理し、向き合うための基本的な考え方を紹介しました。私自身まだまだ勉強中ですが、今回の記事が同じように学んでいる方の参考になれば嬉しいです。
最後までご覧いただき、ありがとうございました。
Discussion