Composerを使ったサプライチェーン攻撃の様子を眺めてみる #phpstudy

Transcript

1. Composerを使った サプライチェーン攻撃の様子を 眺めてみる 第187回 PHP勉強会＠東京 Hideki Kinjyo GitHub: o0h /

   X: @o0h_ [公開用]

2. ※発表後の追記 

3. 以下、発表内容 

4. Composerを使った サプライチェーン攻撃の様子を 眺めてみる 第187回 PHP勉強会＠東京 Hideki Kinjyo GitHub: o0h /

   X: @o0h_ [公開用]

5. 今日の登場人物  Composer パッケージ入れる君 Packagist パッケージ情報を 教えてくれるさん (電話帳的な？)

6. 自己紹介 • 金城秀樹 / きんじょうひでき • GitHub: @o0h / 𝕏

   : @o0h_ • アイコンは美味しい鮭親子丼の写真です • 来週の今頃は札幌にいます • 最近はPodcastをやっています • ハッシュタグ: #readlinefm 

7. 今日の話 ここのところ、 毎週くらいのペースで 脆弱性やサプライチェーン攻撃の話を 聞くじゃんね〜〜〜〜〜〜 

8. 今日の話 Composer界隈の皆さんと、 「それってどうやって起こるの？？」を 見ていきたい！！ 

9. 今日の話 という話です 

10. (裏？ばなし) きっと、今日より踏み込んだ(？)話は PHP Conference Japanで 誰かから聴けるでしょう！！  気になるプロポーザルに ★を付けて盛り上げよう💪 https://fortee.jp/phpcon-2026/

    proposal/all?q=サプライチェーン&f=all

11. 話すこと • Composer+Packagistにおけるサプライチェーンアタックについて • 汚染/侵害されたサードパーティパッケージが混入してくる、 というケースのみに限定します • ソフトウェアサプライチェーンアタックはもっと色々ある 

12. 話さないこと ↓は話さない • サプライチェーンアタック一般への(専門的)な対策方法 • 今回は「Composerの場合」を追うのが主なので 一般的な話は、そういう文献等を当たってください 

13. おしながき 1. その攻撃は、どういう風に実行されるの 2. その攻撃は、どういう風に入り込むの 3. 昨今のComposer側の対策 

14. 参考記事(日本語) • 前に書いた: 『昨今のComposerは(サプライチェーンアタックについて)どうなって るんすかね？？って軽く調べ - 大好き！にちようび』 https://daisuki.nichiyoubi.land/entry/2026/04/03/005936 • あと、コドモンさんの記事:

    『できることから始めるPHPプロジェクトのOSSサプライチェーン攻撃 対策 - コドモン Product Team Blog』 https://tech.codmon.com/entry/2026/04/27/092802 • 自分が勢いで書いたコンテンツより、整ってるんじゃないですかねぇ 

15. その攻撃は、どういう風に実行されるの

16. そもそも超大前提的な 開発者(パッケージのユーザー)が 意図しないタイミングで 変な動きをする！！！ ・・・が困る、って話 

17. 例えるなら "何もしていなのに" 感  インストールしただけなのに コードいじってないのに 手順を守った(or自動化された) やり方なのに

18. (怖い)デモ: いつも通りの`composer install`を ぶっ壊します 

19. None
20. None
21. None
22. None

23. 怖いですね いつもの`composer install`が、 いつもと全然違う挙動 

24. 怖いですね これは「文字列をechoする」だけだが、 「何かを出来ている」状態にありますね？ 

25. 怖いですね 「ざまぁ〜」する代わりに、 「本番用のビルドにおいてAWSのクレデンシャルやSSH キーを環境変数etcから抜いてどっかにPOST」でも 良いわけです 

26. Composerにおいて 「自動的にコードを動かせる」のは、どこ？

27. 自動実行を差し込める所 1. プラグインとして動作して、任意のイベントで発火 ➡ installなど、Composerコマンドの実行時 2. オートロード(イーガーロード)ファイルとして動作させる ➡ Webリクエストやバッチ実行時など、`autoload.php`読込み時 

28. Pluginでの実行

29. Composerのプラグインの仕組み • Composerは、そのコマンド実行時に ライフサイクルに応じたイベントを発行している • プラグインは、そのイベントを購読して、独自処理を発火する仕 組み  主なイベントの例: composer.lockの更新完了時・パッケージのDL時・autoloadファイルの生成時etc

30. 例えばこんなプラグイン • cweagans/composer-patches • パッケージインストール後、vendorファイルに任意のパッチを当てる • php-http/discovery • 依存更新(composer.lock更新)時に、 「対象HTTPクライアントが何かしら入っているか」をチェックする

    

31. さっきのデモの中身 

32. autoloadでの実行

33. 何の変哲もない 四則演算プログラム

34. あやしいパッケージを 入れて・・

35. あやしいパッケージを 入れて・・

36. ただ普通に プログラムを実行

37. 汚染

38. 汚染

39. 何をされているのか • Composerに「オートロード」ありますよね • 「PSR-4」とかのやつです • ↑の場合、composer.jsonにnamespaceと対応ディレクトリを指定する • オートロードの種別に `files`

    というものがあります • これは「クラス(like)定義」以外に使います • 有名どころで言うと、symfony/polyfillとかがメッチャ使う • 指定されたファイルが自動で読み込まれるようになる • PSR-4などは、「遅延読み込み」のための仕組み 

40. さっきのデモの中身: パッケージ定義 

41. さっきのデモの中身: 核心のコード  src/bootstrap.php

42. さっきのデモの中身: autoloadfiles  vendor/autoload.php から 読み込まれているファイル

43. さっきのデモの中身: autoloadfiles  vendor/autoload.php から 読み込まれているファイル

44. さっきのデモの中身: autoloadfiles  vendor/autoload.php から 読み込まれているファイル

45. 要するに

46. Composer利用時に気をつけたいこと • Pluginは比較的自由が効くので、安易に使わない • Composerが提供している安全機構については後述 • autoload.filesは・・・厄介ですねぇ • 使うべきでない、というのもちょっと現実的ではない •

    気をつけることは出来るかもだけど • 両者で、発火タイミングが違う 

47. その攻撃は、どういう風に入り込むの

48. まずは Composer/Packagistの情報管理

49. レジストリ利用者としてのComposer • 今回はデフォルトレポジトリ = Packagistの話に限定しますが • Packagist自体は、パッケージの実コードやバイナリを持たない • パッケージの本体は、(主に)GitHubを案内している •

    代わりに、メタ情報だけを管理している • 提供しているパッケージ名と、バージョンの情報 • 各バージョンに対応するハッシュ(Gitコミットハッシュ) 

50. composer.json  (基本的には) 利用したいバージョンの 「範囲」を指定する

51. composer.lock 

52. composer.lock  バージョンが 明示的に指定され

53. composer.lock  実コードの 取得先が示される

54. パッケージ情報のソース • この辺りの「バージョンとかハッシュとかdistのURL」を 届けてくれているのが、PackagistのAPI • https://repo.packagist.org/p2/***/***.json • Composerはコレを参照して、取り込んでいる 

55. package.json  めっちゃ割愛した 情報

56. package.json  バージョンごとに distが入る

57. ヤバいコードはどうやってくるか

58. composer.lockがない場合 • composer.lockがない(もしくは更新される)場合、 「(制約を満たす範囲で)何が入ってくるかが保証されない」。 • 更新される場合？ • composer update •

    composer require 

59. composer.jsonで「具体的な指定」をしていても？ • 例えば、`composer require cakephp/cakephp:5.4.0` を指定 • ・・・しても、中身が同じ事は保証されていない • Packagistの場合、同じリリース(タグ)での更新が可能

    • force push出来ちゃう 

60. とても分かりやすい話

61. 先日のlaravel-langのやつ • Laravel Lang Compromised with RCE Backdoor Across 700+

    Versions https://socket.dev/blog/laravel-lang-compromise • 権限を取られた(断定してないかも)様子がある • 攻撃者が、org内のコード等を操れる状態に • CIの履歴を見ると、生々しく現場の様子が残ってる 
62. None

63. 過去のタグが (再)pushされている・・

64. CIのジョブに紐づいているコミット 

65. CIのジョブに紐づいているコミット  イーガーロードに 追加されている

66. こうなると、どうなる？ • 「正当だったバージョン」の内容は書き換えられて 「違うコミットハッシュ」になっている • composer.lockが変わっていなければ、 「いま汚染されたファイル」を食わされないで済む • 一方で、composer require/update系の

    composer.lockの更新は、汚染されたバージョンを食う 

67. 昨今のComposer側の対策

68. Plugin周り

69. プラグインは「明示的に許可されたもの」のみ動く • Composerでは、プラグインは予め許可したものしか実行されない • 2.2.0〜 (2021年リリース) • 許可できるのは、PJのrootにある `composer.json`のみ •

    つまり、require/updateで入ったパッケージからは使えない 

70. マルウェアフィルター

71. 汚染されたバージョンのブロック • https://github.com/composer/composer/pull/12766 • 次のバージョン(2.10)から • Packagist側が、「汚染されたバージョン」フラグを提供する これをみて、危ないものが入りにくいようブロックする • Aikido

    Securityによる提供 

72. flagged as malware by Aikido 

73. flagged as malware by Aikido 

74. laravel-langはこんな感じ 

75. None

76. ナイスブロック👏

77. ナイスブロック👏

78. (安定版)バージョンの上書き不可に

79. リリースされたタグは上書きできなくなる • Packagist側の修正 • 1度リリースされたバージョンは、 内容が同一であるものと保証しやすくなる • 5/28(JST)時点で、まだマージされていない • https://github.com/composer/packagist/pull/1742

    • ブログでは「in this week」のリリースと書かれている 

80. その他の動き

81. Transparency Log  https://packagist.org/transparency-log?actor=&user=&vendor=laravel-lang&package=&datetime_from=&datetime_to=2026-05-23T05%3A06%3A32

82. Transparency Log  https://packagist.org/transparency-log?actor=&user=&vendor=laravel-lang&package=&datetime_from=&datetime_to=2026-05-23T05%3A06%3A32

83. 予定されているもの・関心が寄せられているもの • (5/27) An Update on Composer & Packagist Supply

    Chain Security https://blog.packagist.com/an-update-on-composer-packagist- supply-chain-security/ • Coming in the next weeks and months: • Minimum-release-age / cooldown • Longer-term direction: • Mandatory MFA across Packagist.org • Packagist.org hosting immutable build artifacts directly w/SLSA build provenance, Sigstore attestation 

84. 予定されているもの・関心が寄せられているもの • (5/27) An Update on Composer & Packagist Supply

    Chain Security https://blog.packagist.com/an-update-on-composer-packagist- supply-chain-security/ • Coming in the next weeks and months: • Minimum-release-age / cooldown • Longer-term direction: • Mandatory MFA across Packagist.org • Packagist.org hosting immutable build artifacts directly w/SLSA build provenance, Sigstore attestation  補足: 現状、Packagistで配布するメタ情報にある`time`フィールドは、 パッケージの作者が任意に書き換え可能なので信頼しちゃ駄目

85. まとめ/今できること

86. 「何が入っているか分からない」を防ぐ • ちゃんと.lockファイルを使いましょう • なるべく使うプラグインは減らしておいた方が良いかも • require-dev系でプラグインを使いたい時は、本番環境から隔離する • 本番には--no-dev インストールを使う

    • vendor-binプラグインの活用 & 利用環境を分ける • CIで`composer audit` を定期実行するのも 

87. 「何が入っているか分からない」を防ぐ • Lockファイルの差分もPR単位で見るAction • https://github.com/marketplace/actions/composer-lock-diff • ただ、今の時代なら、 このくらいの軽量なものであれば自作しても良いかも • プラグインやGitHub

    Actionsを増やしまくるのに不安がある場合 

88. Composer 2.10を待ちましょう、飛びつきましょう • マルウェアブロック🙌 • 今週リリースらしい 

89. ComposerとPackagistを支えよう  https://github.com/sponsors/composer

90. おしまい！ お付き合いいただき ありがとうございました!!

91. オマケ

92. auditfix的なコマンド

93. なに？ • npmとかには `audit fix` 的なコマンドがあるらしいと聞いた • Composerでも、 「パッチを当てる最小限の変更」ができたら良いのにねぇ 

94. 現状確認

95. 問題アリなver.

96. auditも見てみると

97. 検出されている

98. 検出されている

99. minimal-changesだと

100. 変更無し

101. 通常のupdate

102. 結構versionが変わった

103. コレをどうにかしたい 

104. PoC的なものを作ってみた 

105. audit-fix

106. None
107. None

108. 結果を見てみる

109. None
110. None

111. 参考資料とか

112. 過去に出した資料 • Composerのメタ情報収集の流れについて • Composer 2.0って何？ どう変わるの？ 読んでみました！ (2020) https://speakerdeck.com/o0h/lets-read-composer2

     • 作って理解するComposer <クイックコース> (2024) https://zenn.dev/o0h/books/phpcon-2024-composer-ws • プラグインの仕組みについて • 作って遊ぼう！Composer Plugin (2022) https://speakerdeck.com/o0h/phperkaigi-2022-composer-plugin-b 

113. 他のめっちゃ良い情報 • Jxckさんの記事。必読 • サプライチェーン攻撃への防御策 | blog.jxck.io https://blog.jxck.io/entries/2025-09-20/mitigate-risk-of-oss- dependencies.html •

     GMO Flatt Security CTO米内さんの記事。パッケージマネージャーの比較も • axios, LiteLLM...不使用だったのでOK、ではない。「次に備える」ソフトウェア サプライチェーン侵害への対策 - Speaker Deck https://speakerdeck.com/flatt_security/axios-litellm-dot-dot-dot-bu-shi- yong-datutanodeok-dehanai-ci-nibei-eru-sohutoueasapuraitienqin-hai- henodui-ce