Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
5分で問診!Composer セキュリティ健康診断
Search
コドモン開発チーム
July 19, 2026
Programming
860
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
5分で問診!Composer セキュリティ健康診断
コドモン開発チーム
July 19, 2026
More Decks by コドモン開発チーム
See All by コドモン開発チーム
コドモンに入社してAI活用により、 設計がより重要だと感じた背景
codmoninc
0
33
実装・設計だけでなく、運用・保守にもAIを広げてみた / We Took AI Beyond Coding and Into Operations and Maintenance
codmoninc
0
23
AIが無かった頃の素敵な出会いの話
codmoninc
1
380
アラート疲れからの脱却 - リソースタグで仕分けるSlack通知戦略 / Breaking Free from Alert Fatigue – A Slack Notification Strategy Using Resource Tags for Routing
codmoninc
0
43
SREに優しいTerraform構成 modulesとstateの組み方 / terraform-modules-state-for-sre
codmoninc
0
390
モノリスなプロダクトの「ほどよい」リプレイス戦略 / A "Just Right" Replacement Strategy for Monolithic Products
codmoninc
0
280
Don't Just Patch — MOTTAINAI! Learn Security from Laravel CVE Diffs
codmoninc
0
270
ソースコードで比較する React / Vue / Svelte の セキュリティ設計思想 / security design philosophy react vue svelte
codmoninc
5
660
少人数SREチームが、長寿なシステムを構築・運用するための取り組み / Efforts by a Small SRE Team to Build and Operate Long-Lived Systems
codmoninc
0
380
Other Decks in Programming
See All in Programming
PHP に部分適用が来るぞ!……ところで何それ?おいしいの? #phpcon / phpcon-2026
shogogg
0
560
わからない話を追いかけたら、プログラミング言語を作る側にいた
ydah
3
450
「寝てても仕事が進む」Claude Codeで組む第二の脳
tomoyafujita2016
0
290
Apache Hive: Toward a Cloud Native Lakehouse
okumin
0
180
仕様書を書く前にハーネスを作る - Agent Native開発は「探索を速く、判定を固く」
gotalab555
4
1.5k
テーブルをDELETEした
yuzneri
0
130
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
530
改善しないと、タスクが回らない。 “てんこ盛りポジション” を引き継いだ情シスの、入社3ヶ月の業務改善録
krm963
0
250
FDEが実現するAI駆動経営の現在地
gonta
2
260
20260722_microCMSで考える、AI時代のコンテンツ運用設計
yosh1
0
350
ドリフトを絶対に許さない(?)CDK運用 / CDK Ops with Zero Tolerance for Drifts (?)
akihisaikeda
1
170
為什麼你並不需要ViewModel / No, you don't need a ViewModel
lovee
1
480
Featured
See All Featured
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
230
Documentation Writing (for coders)
carmenintech
77
5.4k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
190
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
200
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
Being A Developer After 40
akosma
91
590k
It's Worth the Effort
3n
188
29k
Everyday Curiosity
cassininazir
0
270
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
460
Typedesign – Prime Four
hannesfritz
42
3.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.4k
First, design no harm
axbom
PRO
2
1.2k
Transcript
5分で問診! Composer セキュリティ健康診断 PHPカンファレンス2026 Akito Tsukahara
自己紹介 塚原 彰仁 @AkitoTsukahara 株式会社コドモン ソフトウェアエンジニア 2歳の息子とトイプードルの父。 2014.10 学生の頃に初のPHPカンファレンスに参加 2026.07
人生で7回目のPHPカンファレンス 2
OSSサプライチェーン攻撃とは コードを直接攻撃せず、 信頼されたパッケージを乗っ取る攻撃 3
OSSサプライチェーン攻撃とは パッケージinstallを実行しただけで、 コード変更なし・ユーザー操作なしで感染 4
axios npm サプライチェーン攻撃(2026/3/31) アカウント乗っ取りによる不正なバージョンを公開 被害規模 • 週次1億ダウンロードの人気パッケージが、わずか3時間で世界中に拡散 • 実害を受けた可能性のある規模:数百〜数百万ユーザー(Microsoft推定) 5
PHPエコシステムでも発生(2026年4月〜5月) • intercom/intercom-php(2026/4/30) ◦ Mini Shai-Hulud(TeamPCP)による組織的攻撃の一部として PackagistのGitタグを改ざん • laravel-lang(2026/5/22-23) ◦
漏洩したGitHub PATを悪用し、4リポジトリで700件超のGitタ グを改ざん 6
皆さんは対策できていますか? 🩺
この診断に、絶食は不要です。 その場での挙手🙋も不要です ⚠ 挙手すると、インシデントとして扱われる可能性が...🙅 8
開発フローと防御ポイント ①取り込む前 ②取り込む時 ③使っている間 選定・検証 インストール 制御・監視 ⓪前提:Composer自体を最新に保つ 9
問診① ⓪前提 Composerのバージョンは 最新ですか? 10
処方① ⓪前提 composer self-update で更新する Composer自体のRCE脆弱性(CVE-2026-40176等)/ 2.10のマルウェア検知・タグ改ざん防止は最新版のみ 11
問診② ①取り込む前 公開直後のパッケージ、 いきなり入れてませんか? 12
処方② ①取り込む前 クールダウンを設定して、 公開直後の数日は様子見を 悪意のあるリリースの多くは数分〜数時間で検知される →数日待つだけでも大半を回避できる 13
処方② ①取り込む前 Renovateの例: “minimumReleaseAge”: “3 days” Dependabotの例: cooldown: default-days: 7
# 未設定だと3日 これが効くのは自動更新の経路だけ 手元で追加する時には注意が必要 14
おまけ:コドモンでの取り組み Lefthookで公開直後パッケージをコミット前にチェック 手動追加におけるクールダウンチェックをカバー git commit Lefthook lock差分を抽出 公開日をチェック パッケージの 更新
pre-commit フックで起動 追加・更新 パッケージを特定 公開直後なら 警告⚠ ⚠ 公開日チェックに利用しているpublished_atが改ざんされたら防げない🙅 15
問診③ ②取り込む時 composer.lock リポジトリにコミット していますか? 16
処方③ ②取り込む時 composer.lock をコミットし、 composer install で運用 依存関係の再現性と改ざん検知のため laravel-lang事例:同一バージョン番号のまま中身だけ差し替え→lock固定+installなら防げた 17
composer.lockの役割(1/2) composer.lockなしの場合 composer.json “pkg”: “^1.0” install 7/20 7/21 7/22 v
1.0.2 v 1.0.3 v 1.0.3 💀 installする度にバージョンが変化する 改ざんされたバージョンを取り込んでしまうリスクがある 18
composer.lockの役割(2/2) composer.lockありの場合 composer.lock “asdf123” install 7/20 7/21 7/22 v 1.0.2
asdf123 v 1.0.2 asdf123 v 1.0.2 asdf123 毎回同じ中身が取り込まれる CI経由でのinstallでも問題なし(バージョン偽装も防げる) 19
問診④ ②取り込む時 composer install に --no-scripts --no-plugins 付けてますか? 20
処方④ ②取り込む時 installでは、依存側のスクリプトを実行させない composer install --no-scripts --no-plugins ⚠ 何にでも付ければ良い訳ではない Laravel等は
package:discoverが必要。必要なスクリプトだけ後から明示的に実行する 21
問診⑤ ③使っている間 CIで composer audit、 実行していますか? 22
処方⑤ ③使っている間 CIパイプラインに composer audit を組み込む(検知したら落とす) composer audit --format=summary ||
exit 1 audit.block-insecure(2.9~)はupdate / require時のみ有効 23
詳細チェックリスト ⓪前提 ◻ Composer自体を最新に保つ ⭐ ①取り込む前 ◻ 公開直後の版をすぐに取り込まない ⭐ ◻
依存追加の前にパッケージの素性を確認 ◻ (組織)取り込み窓口の一元化・ミラー経由 ②取り込む時 ◻ composer.lock をコミット ⭐ ③使っている間 ◻ CI でcomposer auditを実行 ⭐ ◻ プルリクで composer.lock の差分をレビュー ◻ 脆弱性発見から一定時間内に更新するルール ◻ 上流が直らない場合の代替手段(フォーク等) 番外編(CI/CD) ◻ CI に渡すクレデンシャルの最小権限化 ◻ CI/Docker での非root実行 ◻ allow-plugins を許可リスト化 ◻ CIで --no-scripts --no-plugins ⭐ ⭐=本編で紹介した項目 24
Web問診票を用意しました!チェックしてみよう https://akitotsukahara.github.io/composer-health-check/ 25
Web問診票を用意しました!チェックしてみよう https://akitotsukahara.github.io/composer-health-check/ 26
定期的な診断もお忘れなく 💊
None
付録💊
付録|取り込み窓口の一元化(組織向け) ①取り込む前 Packagist.org に直接アクセスしていますか? Private Packagist等のミラーを経由すると: • マルウェア版のダウンロードを組織全体でブロック(古いComposerでも有効) • 依存パッケージが削除されてもビルド継続可能
参考:Blocking malware downloads for every Composer version in Private Packagist 30
付録|composer.lock 差分のレビュー ③使っている間 プルリクで composer.lock の差分、見てますか? • 意図しないパッケージの追加・バージョン変更に気づける最後の目視ポイント • 「なぜこの間接依存が増えた?」に答えられるか
lockが守れるのはinstall時のみ update時の差分レビューが、改ざん参照を持ち込む前の最終防衛 laravel-lang事後調査でも、lockのSHAを上流履歴と突き合わせる方法が感染判定手段に 31
付録|audit.block-insecure の補足 audit.block-insecure は Composer 2.9からデフォルトで true • update/require/remove の依存解決時のみ有効
• composer install には適用されない(lockの再現性維持のため意図的な仕様) なので CIでの composer audit 必須化でカバーする 既知の脆弱性があるバージョンは依存解決の時点で弾かれるが、 lockファイルからのinstallは素通りする 32
付録|minimum-release-age の現状 ①取り込む前 Composer に minimum-release-ageは 現状未実装 • 依存ポリシーの基盤は Composer2.10
で追加済み、cooldownは追加予定 • published_at メタ情報を改ざん不可能にする前提作業の完了後に実装見込み それまでは Dependabot/Renovateのクールダウン設定で代替 npm等の他エコシステムには既に存在する機能 参考:An update on Composer & Packagist supply chain security 33
参考リンク • CVE-2026-40176(Composer Perforceコマンドインジェクション) • Composer & Packagistサプライチェーンセキュリティ最新状況 • Composer
2.10リリース(マルウェア検知・タグ改ざん防止) • Composer 2.9.6リリースノート(CVE-2026-40261/40176修正) • Composer 2.9リリース(audit.block-insecure) • audit.block-insecureの適用範囲(update/require時のみ) • intercom-php侵害の詳細(Composerプラグイン化) • intercom-php GitHub Security Advisory • intercom-php:プラグイン化手口の一次分析(Socket) • laravel-lang侵害の詳細(Snyk Advisory) 34
参考リンク • laravel-lang:lock固定+installで影響なしの分析(StepSecurity) • laravel-lang:lockのSHA監査による感染判定手順(Mend) • axios npmサプライチェーン侵害(CISA Alert) •
axios事件のポストモーテム(axios公式GitHub Issue) • axios事件の技術分析(Microsoft Security Blog) • OpenSSF S2C2F 公式仕様 • Packagist:安定版バージョンの不変化(immutable versions) • Private Packagist:マルウェアダウンロードブロック • Private Packagist:ミラーリング機能 35
None