2025年にShai-Huludが初めて登場したとき、ソフトウェアサプライチェーンにおける教訓は明確に思えました。パッケージのメンテナのアカウントが侵害されると、信頼されているパッケージが悪意のあるコードの配布経路になり得るということです。

それから1年が経ち、この攻撃ファミリはさらに高度化しました。しかし、より重要な教訓は、ソフトウェアのトラストをどう捉えるべきかという点にあります。

最近のShai-Huludの亜種は、npmの認証情報だけでなく、GitHub Actions、クラウドID、KubernetesやVaultのシークレット、OIDCトークン、開発ツールの設定も標的にしています。悪意のあるパッケージの中には、正当なリポジトリやワークフローを通じて、有効な来歴（プロベナンス）メタデータとともに公開されたものさえあります。

これは重要な問題です。なぜなら、署名を最終的な対策とするセキュリティ計画には限界があることを示しているからです。

署名は不可欠です。しかし、署名だけでは、署名対象のソフトウェアが安全かどうかまでは判断できません。

真正性とセキュリティは異なる問いに答える

デジタル署名は、誰が成果物に署名したのか、また署名後に成果物が変更されていないかを確認するためのものです。

これらは極めて重要な保証です。

しかし、ソフトウェアが署名される前に、攻撃者が正規のメンテナ、リポジトリ、リリースワークフローを侵害した場合、結果として生成される署名は有効なままです。つまり、正規のプロセスを通じて作成された真正な成果物であっても、悪意のあるコードが含まれている可能性があります。

Shai-Huludによって、この違いを無視することはますます難しくなっています。

解決策は署名を減らすことではありません。署名と、実際にリリースするソフトウェアの内容を可視化する仕組みを組み合わせることです。

その第一歩は、依存関係を把握することです。

SBOMで依存関係を可視化する

ほとんどのソフトウェアには、オープンソースやサードパーティ製のコンポーネントが含まれており、その依存関係は何層にも及ぶことがあります。こうした依存コンポーネントの一つに脆弱性が見つかったり、侵害されたりした場合、最初に確認すべきことはシンプルです。

そのコンポーネントをどこで使用しているのか？

ソフトウェア部品表（SBOM）がなければ、この問いに答えるために、リポジトリ、ビルドシステム、リリース記録、デプロイ環境を個別に調査しなければならない場合があります。

SBOMは、リリースに含まれるコンポーネントを構造化して一覧化したものです。これにより、特定のパッケージや依存コンポーネントを含むリリースを特定し、必要な箇所に絞って対策を講じることができます。

その価値は、リリース後にリスクが変化した場合に、さらに明確になります。

最近のShai-Huludの活動は、その好例です。2026年9月、3か月以上にわたって活動が確認されていなかった既知の悪意のあるペイロードが、新たに公開されたnpmパッケージ内で再び確認されました。これは新しい技術的な亜種ではありません。既知の悪意のあるコードが再び出現しただけです。

脆弱性についても同じことが起こります。リリース時には問題がないと思われていたソフトウェアでも、数週間後や数か月後に、依存コンポーネントに新たなCVEが割り当てられる可能性があります。

リリース自体は変わっていません。変わったのは、そのリスクに対する認識です。

ソフトウェアのリリース後も継続的な監視が必要

だからこそ、ある時点でのセキュリティチェックだけでは不十分なのです。

チームは、新たな情報によって、すでに使用されているソフトウェアのセキュリティ状態が変化したことを把握する必要があります。そのためには、脆弱性や依存関係に関する情報を、個々のリリースと継続的に紐付けることが重要です。

SBOMと継続的な監視を組み合わせることで、次のような問いに答えられるようになります。

• 影響を受ける依存コンポーネントが含まれている稼働中のリリースはどれか？
• どのバージョンがリスクにさらされているか？
• 新たに特定された脆弱性の深刻度はどの程度か？
• どのリリースを優先的に調査または更新すべきか？
• 修正済みの依存コンポーネントのバージョンは利用可能か？

これにより、SBOMは単なる静的な文書から、実際の運用に活用できる情報へと変わります。

また、ソフトウェア署名とソフトウェアセキュリティの間にある重要なギャップを埋めることにもつながります。

署名は、ソフトウェアが真正であり、変更されていないことを確認するものです。SBOMは、リリースに何が含まれているかを示します。そして監視は、リリースに含まれるコンポーネントに対応が必要になったことを知らせます。

この3つすべてが必要です。

Software Trust Managerで署名とリリースリスク管理を統合

DigiCert Software Trust Managerは、こうしたソフトウェアのトラストを包括的に捉える考え方に基づいて設計されています。

保護の面では、Software Trust Managerはコード署名のガバナンスを一元管理し、安全なハードウェア内で署名用秘密鍵を保護します。また、署名権限を持つユーザを制御し、開発ワークフロー全体でポリシーに基づく署名をサポートします。

可視化の面では、Secure Releases機能により、GitHubのリリースと依存関係、脆弱性、CVSS、SBOM、スキャンステータスの情報を紐付けます。これにより、チームはリポジトリやセキュリティツールに分散した検出結果を手作業で照合することなく、影響を受ける可能性のあるリリースを把握できます。

継続的な監視と修復の面では、Software Trust Managerの対応パッケージを利用することで、脆弱性情報の変化に応じてリリースのリスクを監視できます。対応が必要なリリースについて通知を受け取り、影響を受ける依存コンポーネントや、サポートされている場合は修正済みバージョンの候補など、関連情報を確認できます。また、組織は管理された署名・リリースワークフロー内で、脆弱性やSBOMに基づく条件を設定することもできます。

Secure Releasesは、脆弱性スキャナを置き換えることを目的としたものではありません。その役割は、スキャナの検出結果を、チームが実際にリリースし、保守しているソフトウェアに紐付けることです。

これこそが、Shai-Huludから得られる重要な教訓です。

ソフトウェアトラストは、コードに署名した時点で完結するものではありません。何をリリースしているのかを把握し、リリース後も継続的に監視する必要があるのです。