ISC2 Strategic Congress 2026 — デンバー — 悪意あるパッケージがセキュリティチェックをすり抜けた際、ソフトウェア部品表（SBOM）だけを頼りに状況を判断すると、実際にどのコードが実行され、どのシステムに触れ、侵害がどこまで広がったのかを突き止められず、防御側が苦慮する恐れがあります。
AtlassianのプロダクトセキュリティマネージャーであるDeepam Kanjani氏は、今週開催されたISC2 Security Congress 2026のセッションで、Shai-Huludワームが関与した実際の侵害事例を取り上げました。同氏はこの事例をもとに、ランタイムの可視性、推移的依存関係の管理責任、攻撃者の特定といったインシデント対応の課題を指摘しました。
Shai-Hulud攻撃をウォールームの視点で振り返る
Kanjani氏によると、セッションでは機密保持のため、身元を特定できる情報、数値、出来事の順序をすべて変更したということです。ただし、一人称のウォールーム形式で語られた攻撃手法や技術的な挙動、直面した課題は、大規模なSaaS（Software as a Service）環境で実際に起きた出来事に基づいています。
同氏が説明したインシデントでは、問題のパッケージは一見正規のものに見えました。SHAハッシュは一致し、3,400を超えるGitHubスターを集め、リポジトリも社内のセキュリティツールからは信頼できるものに映っていたといいます。しかし、パッケージの3階層下には、映画『デューン』シリーズに登場する巨大なサンドワームにちなんでshai-huludと名付けられた、悪意ある推移的依存関係が潜んでいました。直接の依存関係ではなかったため、最上位の依存関係監査には表れませんでした。
異変の最初の兆候は、ビヘイビアスキャナーが、実行されるはずのない処理をパッケージが実行していると検知したことでした。ハッシュが一致し、悪意を示す明白な証拠もほかになかったため、インシデント対応担当者は当初、このアラートを誤検知の可能性が高いとして退けました。
さらに、セキュリティチームがSBOMを確認したところ、環境は問題なしと報告されました。しかし、当時は気づいていませんでしたが、そのSBOMは開発スプリント2回分も更新されていなかったと、Kanjani氏は述べています。
対応が進むなかでも、チームはどのサービスがこのパッケージを使っているのかを確信を持って答えられませんでした。侵害指標（IOC）は初期の手がかりにはなったものの、影響を受けたサービスや侵害の広がりを特定するには至りませんでした。実際にどのコードが実行され、何にアクセスできたのかを判断するには、ランタイム上の証拠が必要でした。
ランタイムのテレメトリがなかったため、チームは400を超えるサービスのログを手作業で突き合わせなければならず、侵害が及びうる範囲を確実に把握できませんでした。さらに、インシデント対応担当者が社内の関係者に最初に送ったSlackメッセージが曖昧すぎたことで事態は悪化し、まだ進行中の事案をめぐって複数の調査が並行して立ち上がる結果になりました。
セキュリティチームは、レジストリの所有者、npmメンテナーの履歴、公開者のID、GitHubの記録をたどって攻撃者の特定を試みましたが、すぐに行き詰まりました。リポジトリは正規のプロジェクトからコピーされたもので、公開者の身元やアカウントの履歴も偽造されていたとみられると、Kanjani氏は語りました。
その後、研究者らは、のちのShai-Hulud攻撃の少なくとも一部について、TeamPCPとして追跡されている脅威アクターの仕業だと結論づけています。
インシデント対応担当者への教訓
Kanjani氏が示した最大の教訓は、組織はSBOMや依存関係の一覧にとどまらず、本番環境で実際に動いているものを軸にインシデント対応を組み立てる必要があるということです。セキュリティチームがインシデントを特定し、範囲を見極め、優先順位をつけて封じ込められるよう支援することが重要であり、影響を受けたサービスや侵害の潜在的な範囲をリアルタイムで可視化できるようにすべきだといいます。
「トリアージの対象はランタイムグラフです。依存関係ファイルではありません。ツールもそれを反映したものでなければなりません」と、同氏は述べました。
Kanjani氏は、デプロイ済みのSBOMを72時間以内の新しさに保ち、本番サービスの98%超がその基準を満たすようにすることを推奨しました。あわせて、未知のモジュールのロードを90秒以内に検知できるランタイム機能を有効にすること、社内パッケージ名に似せたパッケージを公開から24時間以内に検知するため、レジストリを毎日チェックすることも勧めています。
同氏は、これらは普遍的なベンチマークではなく、各組織が自らの環境に合わせて調整すべき目標だと説明しました。加えて、セキュリティチームは「誰が」ではなく「何を」行っているかに注目すべきだと、Kanjani氏は指摘します。「IDに関するシグナルは入れ替わりますが、攻撃に欠かせない動作は変わりません。ワームが機能するために必ず行うことを軸に検知を設計してください。誰が操っているかではありません」
セキュリティインシデントに関する関係者とのやり取りは、すべて率直で明確なものでなければなりません。重要なのは誠実であることだと同氏は述べ、そのうえで、想定する受け手に合った言葉で詳細を伝える必要があると付け加えました。
「ごまかしてはいけません。相手が受け止められる形で、現実をそのまま伝えてください」と同氏は語りました。「パニックをあおりたくはないはずです」
翻訳元: https://www.darkreading.com/cyber-risk/sboms-alone-scope-supply-chain-attack
