数時間以内に第一報を、証明でき次第確定回答を、そして状況が変わるたびに続報を送ってください。わかっていること、まだ確認中のこと、次にいつ更新するかを伝えます。「影響なし」はすべて、現在のロックファイルではなく、攻撃期間中にビルドが実際にインストールしたものに基づかせてください。
この記事では、何を、いつ、何を根拠に伝えるかを扱います。調査そのもの、つまり脆弱なコンポーネントが自社製品に含まれているか、いつから含まれているかを突き止める方法については、影響はあるか？新しいCVEを評価する方法をご覧ください。
顧客がパッケージレジストリではなく貴社に尋ねる理由
ある小規模なソフトウェアサプライヤーが話してくれたところでは、広く報じられた攻撃の翌週、クライアントからテキストメッセージが次々と届いたそうです。御社の製品は大丈夫ですか？うちのシステムは大丈夫ですか？彼の顧客は機密データを扱っており、彼のチームにはセキュリティの専門家がおらず、その日のうちに答えが必要でした。
顧客が尋ねているのは、パッケージが侵害されたかどうかではありません。それはレジストリと研究者がすでに伝えています。顧客が尋ねているのは、貴社が出荷したものにそれが含まれているかどうかです。貴社の製品が、顧客にとってのリスクの入り口だからです。顧客にも、同じ質問をしてくる自社の顧客、監査人、規制当局がいます。半導体、産業機器、ヘルスケアといった規制の厳しいサプライチェーンでは、この質問は好奇心ではなく契約上のものです。
また、回答を検証できなければ、顧客は再び尋ねてきます。何の裏付けもない「当社は影響を受けていません」は約束にすぎません。「3月24日から31日までのすべてのリリースビルドを確認し、影響を受けるバージョンをインストールしたものは1つもありませんでした」は、顧客が信頼できる声明です。
最近の4つの攻撃と、それぞれが投げかけた問い
正しい答えは攻撃の手口によって変わるため、テンプレートだけでは不十分です。以下のそれぞれについて、サプライヤーにとって「影響あり」が何を意味するかを1つの事実が決めます。
xz Utilsのバックドア（CVE-2024-3094）、2024年3月29日に公表。 Andres Freundが発見したのは、xzのバージョン5.6.0と5.6.1に仕込まれたバックドアでした。リリースのtarballにはGitリポジトリにないコードが含まれており、それがビルド中にバックドアを注入しました。NVDとRed HatはいずれもCVSS 3.1で10.0と評価しています。影響が及んだのは主にローリングリリースやテスト版のディストリビューションで、Debianのtesting、unstable、experimental、Fedora Rawhideと41、openSUSE Tumbleweed、Kaliです。安定版のリリースは影響を受けませんでした。投げかけられた問い：当社が出荷したイメージやデバイスにxz 5.6.0または5.6.1が含まれているか。各ビルドはどのベースイメージを使ったか。
Shai-Hulud npmワーム、2025年9月から波状的に発生。 感染したパッケージはインストール時にスクリプトを実行し、npm、GitHub、クラウドの認証情報を盗み、それを使ってさらに多くのパッケージの感染版を公開します。投げかけられた問い：感染したバージョンをインストールしたCIジョブはあるか。当社の公開用トークンは漏えいしたか。漏えいしていれば、当社が拡散源になります。当社のShai-Huludの解説に、すべての波と確認方法をまとめています。
PyPI上のLiteLLM、2026年3月24日。 バージョン1.82.7と1.82.8が、プロジェクトのGitHubリポジトリには一度も存在しなかった認証情報窃取コードとともに、PyPIに直接アップロードされました。1.82.8では、.pthファイルが、LiteLLMがインポートされたときだけでなく、Pythonインタープリターが起動するたびにペイロードを実行し、環境変数、SSH鍵、クラウドの認証情報、Kubernetesのシークレットを収集しました。HiddenLayerはこの攻撃をTeamPCPと結び付けています。TeamPCPは同じ月にTrivyとCheckmarxのツールも攻撃しました。初期侵入の経緯について、LiteLLM自身のアドバイザリは2つの説明を挙げています。CIのセキュリティスキャンのワークフローにあったTrivyの依存関係が原因だとする一方で、メンテナーのPyPIアカウントが侵害された可能性もあるとしています。影響期間でさえ、同じアドバイザリの中で食い違っており、ある箇所では約40分、別の箇所では10:39から16:00 UTCとされています。投げかけられた問い：ビルドや出荷したコンテナにそれらのバージョンが含まれていたか。その環境にはどんなシークレットが存在したか。
npm上のaxios、2026年3月31日。 攻撃者がメンテナーのnpmアカウントを乗っ取り、axios 1.14.1と0.30.4を公開しました。これらは依存関係[email protected]を追加しており、そのインストールスクリプトがmacOS、Windows、Linux向けのリモートアクセス型トロイの木馬を設置しました。Datadogは期間を00:21から03:25 UTCとしており、Snykによればバージョンが削除されたのは03:29 UTCです。投げかけられた問い：その期間にそれらのバージョンを解決したビルドはあるか。期間より前にコミットされたロックファイルは、それを使ったビルドについては「いいえ」と答えてくれますが、ロックファイルなしでnpm installを実行したビルドについては何も教えてくれません。
| 攻撃 | エコシステム | 影響を受けるバージョン | 期間 | サプライヤーにとっての「影響あり」の意味 |
|---|---|---|---|---|
| xz Utils | Linuxディストリビューション | 5.6.0、5.6.1 | 2024年3月29日の公表までの数週間 | 影響を受けるディストリビューションをベースにしたイメージやデバイスで出荷した |
| Shai-Hulud | npm | 波ごとに数百のパッケージ | 波ごとに数時間から数日 | それを使ってビルドし、自社のトークンが拡散に使われた可能性がある。出荷した可能性もある |
| LiteLLM | PyPI | 1.82.7、1.82.8 | 2026年3月24日10:39 UTCから（終了時刻は情報源によって異なる） | それを使ってビルドしたか出荷した。その環境のシークレットが盗まれた可能性がある |
| axios | npm | 1.14.1、0.30.4 | 2026年3月31日、およそ00:21から03:25 UTC | 期間中にそれを使ってビルドした。トロイの木馬はビルドマシン上で実行された |
サプライチェーン攻撃ではない重大な脆弱性でも、同じ問いが生じます。2026年10月にPHP2Shellが悪用されたとき、PHPを同梱するあらゆる製品の顧客が、自分たちのどのバージョンに影響を受けるPHPが含まれているかを尋ねました。以下の手順はそのまま当てはまります。
回答には3つの段階がある
| 段階 | タイミング | 送る内容 |
|---|---|---|
| 第一報 | ニュースから数時間以内 | わかっていること、確認中のこと、次の更新時期 |
| 確定回答 | 証明でき次第。通常は初日 | 特定のバージョンについての「影響なし」、または対応方法を添えた「影響あり」 |
| 続報 | 修正の出荷時、新たな事実の判明時、ケースの完了時 | 同じ通知の改訂版 |
最初の1時間：第一報
第一報（holding statement）とは、事実が出そろう前に最初に出す公式の声明です。真実を、素早く伝えてください。沈黙は憶測で埋められ、何の連絡も受けない顧客は、貴社が気付いていないと考えます。
- 誰が、どこで。 名前のある送信者を1人決め、顧客が使ったチャネルと自社のセキュリティページで伝えます。その場しのぎの個別返信より、共通の文面を1つ用意する方が優れています。内容が一貫し、法務のレビューも1回で済みます。
- 含める内容。 攻撃を把握していること、自社製品とビルドシステムを確認中であること、現時点でわかっていること、次の更新時期、問い合わせ先です。
- 含めてはならない内容。 確認前の「当社は影響を受けていません」、攻撃者についての憶測、他者への責任転嫁です。
テンプレート1：第一報
件名：[攻撃名]に関する当社の第一報
[パッケージまたはプロジェクト]（[影響を受けるバージョン]、[日付]公開）が侵害されたとの報告を把握しております。現在、当社のセキュリティチームが、[製品]のすべてのリリースおよび当社のビルドシステムについて、影響を受けるバージョンが含まれていないかを確認しております。現時点では、[確認済みの製品に影響を受けるバージョンは見つかっておりません／確認はまだ完了しておりません]。[日時、タイムゾーン]までに続報をお送りいたします。それまでの間にご不明な点がございましたら、[担当者名、セキュリティ窓口のアドレス]までお問い合わせください。確認が完了するまで、影響について推測でお伝えすることはいたしません。テキストメッセージやチャットであれば、2文で十分です。
[攻撃名]による侵害について把握しており、現在[製品]のすべてのリリースと当社のビルドを確認しております。[時刻]までに確定した回答をお送りいたします。3つのテンプレートはすべて、必要になる前に弁護士の承認を得ておいてください。
初日：証拠とともに確定する
考えられる結果は2つあり、それぞれに別の証拠が必要です。「影響なし」と回答するには、次のものを集めます。
- 影響を受けるパッケージとバージョン（アドバイザリまたは研究者の解説から）
- 自社製品と、顧客が実際に実行しているバージョン
- それぞれのバージョンについて、それを生成したビルドと、そのビルドがインストールしたものの記録（現在のロックファイルではなく）
- 攻撃期間中に実行されたすべてのビルド（リリースを生成しなかったCIジョブも含む）
- トークンを盗むワームの場合、悪意のあるコードを実行し得たジョブにCIのシークレットが存在したかどうか
それぞれを特定する方法は、影響はあるか？新しいCVEを評価する方法で解説しています。
出すすべての声明は、示せるものに裏付けられていなければなりません。
| 声明 | 示せなければならないもの | それだけでは不十分なもの |
|---|---|---|
| 「製品Xのバージョンyにはパッケージzは含まれていません」 | バージョンyのリリースビルドから記録したSBOM | 現在のリポジトリのスキャン |
| 「当社のビルドはいずれも侵害されたバージョンをインストールしていません」 | 期間中のすべてのビルドのインストール記録 | 一部のジョブが迂回するロックファイル |
| 「当社のリリースパイプラインは侵害されていません」 | 期間中のネットワークとシークレット使用の記録 | アラートがなかったこと |
| 「バージョンyをお使いのお客様は、アップグレード後は安全です」 | 修正済みビルドの記録と、ローテーションした認証情報 | 変更履歴の記載 |
テンプレート2：影響なし
件名：[攻撃名]：[製品]は影響を受けておりません
[パッケージ]の侵害（[影響を受けるバージョン]）に関する確認が完了いたしました。[製品]の以下のバージョンは影響を受けておりません：[確認した製品とバージョンの一覧]。[開始日]から[終了日]までに実行されたすべてのリリースビルドとCIビルドを確認いたしました。本声明は、当社の現在のソースコードのスキャンではなく、各リリースビルドがインストールしたコンポーネントの記録に基づいております。これらのビルドのいずれも、影響を受けるバージョンをインストールしておりません。根拠が必要な場合は、ご利用中のバージョンのSBOM、またはVEXステートメントをお送りいたします。この評価を変える事実が判明した場合は、改めてご連絡いたします。お問い合わせ先：[担当者名、セキュリティ窓口のアドレス]「影響なし」は特定のバージョンについて述べてください。「100%安全」とは決して書かないでください。顧客がその後SBOM全体を求めてきた場合は、顧客からのSBOM要求への対応をご覧ください。
テンプレート3：影響あり（緩和策付き）
件名：[攻撃名]：[製品]バージョン[x～y]をご利用のお客様へ、ご対応のお願い
[パッケージ]の侵害に関する確認の結果、[製品]のバージョン[x～y]が影響を受けていることが判明いたしました。影響を受ける最初のビルドは[日付]に作成されたものです。[日付]にリリースしたバージョン[z]には、[パッケージのバージョン]は含まれておりません。
影響の内容：[平易な言葉でのリスクの説明。例：「これらのバージョンに組み込まれたコンポーネントが、実行中のシステムから外部のサーバーへ認証情報を送信する可能性があります」]
今すぐ行っていただきたいこと：[製品] [z]へのアップグレードをお願いいたします。すぐにアップグレードできない場合は、[緩和策。例：一覧に記載したホストへの外向き通信をブロックする]。[環境]で[製品]のバージョン[x～y]をご利用になっていた場合は、そこで利用可能だった[認証情報または鍵]をローテーションしてください。
当社の対応：影響を受けるバージョンを当社のビルドから除去し、クリーンな依存関係から[製品]を再ビルドし、当社のビルドシステムが使用する認証情報をローテーションし、[その他の対応]を実施いたしました。[必要に応じて、関係当局に報告済みです。]
次回の続報は[日付]までに、状況に変化があればそれより早くお送りいたします。お問い合わせ先：[担当者名、セキュリティ窓口のアドレス]「影響あり」の通知は法的義務になる場合もあります。後述の報告義務のセクションをご覧ください。
VEXとCSAFの位置付け。 「影響なし」や「修正済み」の声明はVEXとして公開でき、顧客のスキャナーはそのパッケージを検出しなくなります。大口顧客は機械可読なアドバイザリも期待する場合があり、その多くが求める形式はCSAFです。
続報：きちんと完了させる
修正を出荷したとき、調査で新しい事実が判明したとき、そしてケースを完了するときに最終の連絡として、続報を送ります。インシデントごとにアドバイザリを1つにし、毎回新しいものを送るのではなく改訂してください（置き換えずに更新する）。誰に、いつ、何を伝えたかを記録しておきます。次の監査や顧客のセキュリティ質問票で尋ねられます。
まだわからないときの伝え方
「まだわかりません」は、後で撤回しなければならない「影響なし」よりも信頼を築きます。誰も不安にさせずに誠実に伝えられる表現は次のとおりです。
- 「これまでに確認した[製品]では、[パッケージ]は見つかっておりません。[残りの製品またはビルドシステム]を引き続き確認しており、[時刻]までにご報告いたします。」
- 「お客様がご利用中のバージョンは、攻撃期間より前にビルドされたものです。その後のビルドで置き換えられていないことを確認しております。」
- 「当社のビルドシステムで影響を受けるバージョンが実行されたかどうかを確認しております。お客様がインストールされている製品については別の問題として、両方についてご回答いたします。」
避けるべき表現：
- 「一切影響はありません」
- 「完全に安全です」
- 「いかなるサプライチェーン攻撃の影響も受けていません」
- 「当社のスキャナーでは何も見つかりませんでした」
攻撃が報告義務になるとき
EUでデジタル要素を含む製品を販売している場合、Cyber Resilience Actの報告義務は2026年9月11日から適用されています。この日、ENISAはSingle Reporting Platformを公開しました。製品の積極的に悪用されている脆弱性、または製品のセキュリティに影響を及ぼす重大なインシデントが発生した場合、それを認識してから24時間以内の早期警告、72時間以内の通知、そして最終報告が必要です。これらはプラットフォームを通じて、調整役のCSIRTとENISAに提出します。手順はCRAガイドで解説しています。
出荷した依存関係が侵害されていた場合や、自社のビルドパイプラインが侵害された場合に、これらの定義に該当するかどうかは、この記事ではなく貴社と弁護士が判断すべきことです。用語は規則が定義しています。
- 「積極的に悪用されている脆弱性」とは、「悪意のある行為者がシステム所有者の許可なくシステム内で悪用したという信頼できる証拠がある脆弱性」です（第3条第42号）。
- インシデントが重大とされるのは、「デジタル要素を含む製品が、機微なもしくは重要なデータまたは機能の可用性、真正性、完全性または機密性を保護する能力に悪影響を及ぼす、または及ぼし得る」場合、あるいは製品またはユーザーのシステムにおいて「悪意のあるコードの導入または実行につながった、またはつながり得る」場合です（第14条第5項）。
第14条第8項は、ユーザーに対する義務を追加しています。影響を受けるユーザー、および適切な場合にはすべてのユーザーに、脆弱性またはインシデントと、適用できる緩和策を、「適切な場合には、容易に自動処理できる構造化された機械可読な形式で」通知することです。テンプレート3は、この義務を果たす一部になり得ます。
ほかの制度も適用されます。NIS2のもとでは、必須事業体と重要事業体が重大なインシデントをCSIRTまたは所管当局に通知します。また、多くの顧客との契約には、独自の期限を伴う独自の通知条項があります。
次の攻撃に備える
- 各リリースビルドがインストールしたものの記録を、製品のサポート期間中保持する（ビルド時のSBOM）。
- どの顧客がどのバージョンを使っているかの一覧。
- 法務の承認を得た上記の3つのテンプレート。
- 顧客の種類ごとに、名前のある送信者とチャネル。
- 更新情報を掲載するセキュリティページと
security.txtファイル（協調的脆弱性開示）。 - CIの外向き通信の制御。侵害されたパッケージが、ビルドに不要なホストへシークレットを送信できないようにします（GitHub Actionsのegressポリシー）。
インシデントが1件ずつではなく数百件単位で届く場合は、PSIRTをスケールさせる方法をご覧ください。
CRACIの役割
上の証拠の表は、繰り返し1つのものを求めています。各リリースビルドがインストールしたものの記録です。それこそがCRACIが保持するものです。CRACIはGitHub Actionsのビルドを自社のランナーで実行し、インストールスクリプトが取得したパッケージやキャッシュから復元されたパッケージを含め、各ジョブが実際に取り込んだすべてのパッケージを記録します。過去のすべてのビルドのSBOMが保持されるため、「期間中にaxios 1.14.1をインストールしたビルドはあったか？」には、影響を受けていた期間とともに、保持期間の範囲でさかのぼってビルド履歴から答えられます。
xzのバックドアのように、CVEが公開されている既知の悪意のあるリリースは、ほかの脆弱性と同様に検出され、ポリシーゲートでそれらを含むビルドをブロックできます。CRACIは、新しい悪意のあるパッケージを挙動や評判から検出することはしません。
CRACIのegressポリシーは、ビルドに不要なホストへの接続をブロックするため、誰も見たことのない攻撃であっても、悪意のあるインストールスクリプトが外部に送信できるものを制限します。顧客から証拠を求められたら、その顧客が使っているバージョンのSBOMをCycloneDXまたはSPDXでエクスポートして送ることができます。CRACIはVEXに対応しています。
「影響を受けていたか」にビルド履歴から答える。あるいは、サプライチェーン攻撃の仕組みをご覧ください。
CRACIが適さない場合
- コミュニケーションそのものの支援が必要な場合。 広報や法務の助言は別の仕事です。
- 影響を受けたソフトウェアがCRACIでビルドされていない場合。 CRACIが記録するのは、CRACIのランナーで実行されるGitHub Actionsのビルドです。ほかのCIシステムはロードマップにあります。
- 自社でビルドしていないベンダーの製品に関する問いである場合。 ベンダーのSBOMはCRACIに追加できますが、答えの質はベンダーのSBOMの質で決まります。
- アドバイザリが出る前に、まったく新しい悪意のあるパッケージを捕捉する必要がある場合。 CRACIは、CVE付きのアドバイザリが公開された時点で既知の悪意のあるリリースを検出します。マルウェアを挙動や評判から検出することはしません（ゼロデイ脆弱性への対応）。
よくある質問
サプライチェーン攻撃がニュースになったら、顧客に何を伝えればよいですか？
数時間以内に第一報を送ります。攻撃を把握していること、製品とビルドを確認中であること、現時点でわかっていること、次の更新時期を伝えます。続いて、ビルドの記録で裏付けられ次第、特定の製品バージョンについての確定回答を送り、状況が変わったら続報を送ります。
第一報には何を書くべきですか？
何が起きたかを1文で、自社製品とビルドシステムを確認中であること、これまでにわかったこと、次の更新時刻、問い合わせ先です。確認前に「影響なし」と書いたり、攻撃者について憶測したり、誰かに責任を転嫁したりしてはなりません。
過大な約束をせずに「影響を受けていません」と伝えるには？
確認した製品とバージョン、確認したビルドの期間、使った証拠（各リリースビルドがインストールしたコンポーネントの記録など）を明記します。それらのバージョンについて「影響なし」と述べ、SBOMまたはVEXステートメントの提供を申し出て、状況が変わったら更新すると約束します。「100%安全」や「完全に安全」は避けてください。
「影響を受けていた」という顧客への通知には何を含めるべきですか？
影響を受ける製品とバージョン、いつからどの修正済みバージョンまでか、平易な言葉でのリスク、顧客が今すべきこと（アップグレード、認証情報のローテーション、ホストのブロック）、自社がすでに行ったこと、次の更新時期、問い合わせ先です。
「影響なし」の声明は、どんな証拠で裏付けるべきですか？
顧客が実行している各バージョンについて、それを生成したビルドがインストールしたものの記録です。現在のロックファイルではありません。さらに、攻撃期間中に実行されたすべてのビルドの記録と、認証情報を盗む攻撃の場合は、悪意のあるコードを実行し得たジョブにシークレットが存在したかどうかを加えます。
Cyber Resilience Actのもとで、サプライチェーン攻撃を報告する必要がありますか？
その可能性があります。2026年9月11日から、EUで販売されるデジタル要素を含む製品のメーカーは、積極的に悪用されている脆弱性と、製品のセキュリティに影響を及ぼす重大なインシデントを報告しなければなりません。24時間以内の早期警告、72時間以内の通知、そして最終報告です。特定の攻撃が該当するかどうかは、貴社と弁護士が判断すべきことです。
顧客にはどのくらい早く返信すべきですか？
数時間以内に第一報を送ります。確認中であることと次の更新時期しか伝えられなくても構いません。確定回答は、証明でき次第送ります。素早く誠実な「確認中です」は、遅れて届く「影響なし」よりも信頼につながります。
