CIをサプライチェーン攻撃から守るためのversion pinning

CIをサプライチェーン攻撃から 守るためのversion pinning PHPカンファレンス愛媛2026 takaram (@takaram71)

サプライチェーン攻撃 ● OSSライブラリなどに攻撃コードが仕込まれる ● 利用したり、インストールするだけでもマルウェアに感染 ○ APIトークン、ソースコード流出 ○ 本番のコードにバックドア ○ 社内ネットワークに侵入 → ランサムウェア

サプライチェーン攻撃 ● 利用者の多いnpmパッケージなどが狙われがち ● Composerパッケージが侵害された事例も ○ 今年5月: laravel-lang/lang など ○ https://yamory.io/blog/laravel-lang-supply-chai n-attack

• https://yamory.io/blog/laravel-lang-supply-chain-attack

今回のLT ● CI環境でのサプライチェーン攻撃対策 ● Why? ○ CI環境は毎回インストールから始める ○ 無対策だと侵害されたバージョンをインストールしちゃうかも

よくある被害パターン ● 昨日までは問題なかった → 同じCIを今日動かしたら被害に遭った ● 昨日と今日で異なるものがインストールされている ● 常に同じバージョン、同じコードがインストールされるように 固定する = version pinning

version pinningの対象 ● Composer, npmなどのパッケージ ● サードパーティAction (e.g. actions/checkout) ● Dockerイメージ ● GitHub Releasesからダウンロード

Composer, npmなどのパッケージ ● lockファイルをコミットする ○ composer.lock / package-lock.json ● 常に同じものがインストールされることが保証される ● CIで composer require hoge/fuga:^1.0 もNG

サードパーティAction ● actions/checkout@v7のv7はGitタグ ● @の後ろに書けるもの ○ タグ、ブランチ：中身が後から変わりうる ○ コミットハッシュ：後から変わらない ←採用

サードパーティAction ● uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 ○ 末尾にコメントでどのバージョンか示すのが一般的

サードパーティAction ● gh actions-lock ○ Technical Preview (2026/10/03時点) ○ .github/workflows/actions.lockで間接依存まで固 定 ● 将来的にはこっちに乗り換えることになるかも？ ● 参考: GitHub Actionsにロックファイルが来るぞ

• https://github.com/github/gh-actions-lock
• https://qiita.com/access3151fq/items/70a93f08bffd9c5f09a5

Dockerイメージ ● タグとともにイメージのdigestを渡す ● php:8.5.10@sha256:df50257c90ad9a53052fb4e9c 6fdba8262cf72ca9e9a048b7c89f74c8d23fc0d ● Dockerfileだけではない ○ Docker Composeのcompose.yaml ○ GitHub Actionsのワークフローファイル

GitHub Releasesからダウンロード ● latestではなく特定のバージョン ● 既存のリリースも内容差し替え可能 ● 追加でいずれかを検証 ○ Attestation（構成証明） ○ チェックサム ■ Releaseページのchecksum.txtは改竄されうるので注意

GitHub Releasesからダウンロード

対策 ● これで皆さん明日から対策できますね！

対策 ● これで皆さん明日から対策できますね！ ● 半年後も忘れずに全部対応できる？ ● 他のチームメンバーは？ ○ lockファイルは一度コミットしたら大丈夫そうだが……

対策を強制する サードパーティAction / Dockerイメージ ● pinact ● dockerfile-pin ○ pinされた状態に更新 ○ pinされていないファイルを検知 ■ CIに入れると強制できる

• https://github.com/suzuki-shunsuke/pinact
• https://github.com/azu/dockerfile-pin

対策を強制する GitHub Releasesからダウンロード ● 仕組み的な強制が難しい ● インストールをmiseに寄せる ○ attestation / チェックサムを自動で検証 ※ ○ GHA上はjdx/mise-actionで ※ attestationは対応リポジトリのみ、チェックサムはlockファイル作成済みの場合等のみ

• https://mise.jdx.dev/
• https://github.com/jdx/mise-action

覚えておいてほしいこと ● 常に全く同じライブラリ・ツールが使われるようにする ● バージョン番号の明示だけでは足りないこともある

● 荒巻拓哉 自己紹介 ● X: @takaram71 GitHub: @takaram ● バックエンドエンジニア @株式会社 ラクス ○ 問い合わせ自動応対システムの 開発 ● 大阪から来ました 人生初愛媛！

• https://x.com/takaram71
• https://github.com/takaram

おまけスライド

version pinning以外の対策 ● Composer自体をバージョンアップ ○ 最近のバージョン (2.9, 2.10) は対策を強化している ○ composer self-updateだけでセキュリティ強化 ● npm, pnpmなども同様

Immutable Release ● GitHub ReleasesはImmutableになっていると安心 ○ タグのforce pushやasset差し替えをGitHubが拒否して くれる ○ Attestation自動対応 ● リポジトリごとに設定で有効化する ○ 使いたいリポジトリが未対応ならIssueでお願いするといい かも ○ リリース済みのバージョンは遡ってImmutableにはならな い

ライブラリ更新 ● version pinningして放置すると、古いバージョンを使い 続けることになる ● RenovateやDependabotでアップデートできるように する

被害の最小化 ● 攻撃を受けないことも重要だが、万が一の際の被害を最小 化するのも大事 ○ 権限の最小化 ■ permissions設定 ■ secretsのAPIトークン ○ 長命なトークンを使わない仕組みを検討