導入：なぜ“トロイ化OSS”がいま問題なのか
オープンソースの依存関係に対する“トロイ化（trojanized）”攻撃が頻発しています。代表的な事例として、2025年9月に確認された「Shai‑Hulud」キャンペーンは多数のnpmパッケージを改竄し、インストール時に自動実行されるライフサイクルフックで侵害を広げました。
さらに2026年3月には人気ライブラリが短時間で悪性バージョンに差し替えられた事例が報告され、2026年6月にはインストール前後のフックを悪用してBunランタイム経由でペイロードを実行する手口が技術報告として公開されました。これらは開発者マシン、CIランナー、コンテナイメージまで攻撃対象を拡張します。具体的な日付は、Shai‑Huludの波（2025年9月）、Axiosの改竄（2026年3月31日報告）、およびMicrosoft／複数の解析で指摘されたpreinstall→Bun経路（2026年6月公開）です。
この状況に対処するうえで、SBOM（Software Bill of Materials）による「何が使われているか」の可視化と、ランタイムの行動シグネチャ（プロセスチェーン、ネットワーク挙動、ファイル操作パターンなど）による実行時検知を組み合わせることが実用的な防御になります。本稿ではCI統合からアラート設計、運用フローまでの実務的手順を示します。
第1部：SBOMを“書類”にしない — CIでの実用化パターン
SBOMは生成して終わりにしては意味がありません。CIパイプラインに組み込み、アーティファクトごとに差分・署名・ポリシー評価を行うことで実効性が出ます。以下は実務パターンです。
推奨ワークフロー（要点）
- ビルドごとにSBOM（SPDX/CycloneDX）を生成し、ビルド番号・コミットSHAと紐付けてアーティファクトと同梱する。
- SBOMの差分チェック：依存の追加・バージョン変化を自動で差分表示し、無承認のランタイム変更（例：preinstallスクリプトの追加）をCIゲートで拒否する。
- SLSAなどのビルドインテグリティ基準を適用して署名付きアーティファクトのみを促進する（署名チェーンを保存）。
- SCA（Software Composition Analysis）による既知脆弱性検出に加え、署名・メンテナー署名（maintainer metadata）と発行元の整合性チェックを行う。
CIでの具体的ルール例
| ルール | 理由 | アクション |
|---|---|---|
| SBOM差分にライフサイクルフック追加 | preinstall/postinstallは自動実行リスク | レビュー要求 or 自動拒否 |
| 未知の外部ダウンロード（build時に外部URL呼び出し） | ランタイムで重いペイロードを拾われる | ネットワークブロック／手動承認 |
| 新しいメンテナーパブリッシャー（owner変更） | 乗っ取りの兆候 | 警告＋ロールバック |
SBOMを単なるコンプライアンス資料にしないため、CIポリシーは「差分検知→自動ゲート→人のレビュー」を高速に回せる設計が不可欠です。Security Boulevardらの議論が示すように、SBOMを『生きたデータ』として運用する実装が効果的です。
第2部：ランタイム行動シグネチャで『実行』を捕まえる
多くのトロイ化OSSは〈静的ファイルだけを改竄〉するのではなく、インストール時（preinstall/postinstall）や起動時に外部ランタイムを呼び出して実行します。例えばnode→shell→bun→ペイロードという異常なプロセスチェーンは検出指標になります。
重要なテレメトリと行動シグネチャ
- プロセスチェーンの異常：標準的なノード実行の背後に未知のランタイム（例：bun）やスクリプト挿入があれば高リスク。
- ライフサイクルフックの実行ログ：npm/pip等のlife-cycleフック実行痕跡はCI/開発用VMで特に注視。
- アウトバウンド通信の特徴：ベースライン外のドメイン、短期間で多数の接続、C2プロトコル類似のトラフィック。
- ファイル操作のパターン：暗号化済みペイロードの展開、自己複製の痕跡、設定ファイルの隠蔽。
アラート設計の実務ルール
- アラートはSBOMアトリビュートで優先度を付ける：疑わしい挙動がSBOMに未記載のランタイムや外部ダウンロードを伴う場合は高優先。
- トリアージ用の自動エンリッチメント：アラートに該当アーティファクトのSBOM、ビルドID、パブリッシャー情報を添付する。
- 誤検知低減：開発環境では検出閾値を緩め、本番ランタイムでは厳格に。CIランナーは‘高信頼’でない限り隔離して検査。
- プレイブックを用意：検知→CI停止→アーティファクト隔離→SBOM差分確認→フォレンジック（プロセスチェーン＋ネットワーク）→ロールバック／通知。
運用上は、Sysmon（Windows）やauditd（Linux）といったホスト監視、EDR/XDRのプロセスチェーン分析、ネットワークサンドボックスでのダイナミック解析の組合せが有効です。実務ではこれらをSOARプレイブックで自動化し、SBOMからの証拠を迅速に付加していくことが鍵となります。