導入：なぜ今、OSS依存の監視が最優先か
企業やプロダクトが依存するオープンソース・エコシステムは、開発速度を支える一方で「広がりやすい侵入経路」となっています。2024～2025年にかけて、npm／PyPIなどでのマルウェアやタイポスクワッティング、メンテナアカウントの乗っ取りを起点にした侵害が相次ぎ、短時間で多数のプロジェクトへ波及する事例が増えています。これらの事例は、依存関係の可視化不足と配布プロセスの信頼性欠如が主因であると指摘されています。
本稿は「侵害の早期兆候（どのファイル・挙動を観るか）」「メンテナ／消費者が行うべき監査手順」「運用で継続的に監視・対応するための仕組み（SBOM、SLSA、署名ツール等）」を実務目線で整理します。
侵害の代表的な兆候（Telemetry と静的サイン）
侵害を早期に検出するためには、幾つかの高いシグナルを継続的に監視することが重要です。主なポイントは以下のとおりです。
- 不審なインストールスクリプト（preinstall/postinstall）：npmや一部のパッケージはインストール時にスクリプトを自動実行できます。最近の大規模キャンペーンでは、postinstallなどのスクリプトが悪用され、インストール直後に不正コードを実行する手口が確認されています。CIやエンドポイントでのインストール時にこれらのスクリプトが実行された履歴は重要な検出ポイントです。
- コードの難読化／バイナリ埋め込み：突然の難読化、長大な一行化、暗号化ルーチンや外部URL呼び出しの挿入は警告サインです。静的解析で急増した難読化率に着目するツールが有効です。
- 突然のパッチリリースやメンテナのアクティビティ変化：短期間で同一パッケージの複数パッチが配布された、あるいは公開鍵・署名が消失している等は危険信号です。維持管理者のログイン元や操作時間の急変も確認します。
- 出所（provenance）や署名の欠如・不整合：ビルド証跡（provenance）や署名がない、あるいは透明性ログに記録されていない場合、アーティファクトの改竄検知が難しくなります。署名・透明性ログ（Rekor等）の不整合は高信頼なシグナルです。
- 依存の二重名（typosquatting）や交差エコシステム混乱：似た名前のパッケージ、あるいはnpmとPyPIをまたいだ名前の混乱を利用する攻撃が続いています。パッケージ名の類似度評価とホワイトリスト運用が有効です。
これらのシグナルは単独では誤検知を生みます。重要なのは複数シグナルの相関（例：突然のpatch + postinstall + provenance欠如）でリスクを高信頼に特定することです。
メンテナ／消費者が行うべき実務的チェックリスト
以下は、ソフトウェア供給側（メンテナ）と受け手（利用組織）それぞれが即実施できる具体的な項目です。
メンテナ（パッケージ提供者）向け
- アカウント保護と管理：2段階認証（2FA）を必須化し、CI・レジストリのAPIキーは短寿命化・ローテーションします。侵害時にキーを失効できる手順を整備すること。
- 署名と透明性ログの採用：アーティファクトに対する署名と、Rekor等の透明性ログへ登録するワークフローをCIに組み込む（sigstore / cosign 等の利用推奨）。これにより配布物の真正性を検証可能にします。
- 再現可能ビルドとProvenance：ビルドの証跡（in-toto / SLSAのprovenance）を残し、どのソース・ツールチェーンで作られたかを記録します。SLSAのレベル定義を参考にビルドの信頼度を上げること。
- 最小権限のCI構成：CI上のトークンは最小権限で、PRマージやリリース操作は多要素承認（ブロッカー）を用いて人の介在を確保する。
- 自動テストとシグナル検査：パッケージの新バージョンを公開する前に静的解析・難読化検出・postinstallフラグ検査をCIで自動化する。
消費者（利用組織／開発チーム）向け
- SBOMの生成と運用：SBOMを生成・保管し、依存一覧を自動で継続的に照合する。SBOM運用はNIST/CISA等のガイダンスに沿って設計するのが実務的です。
- ロックファイルと固定化（lockfile／ふるい分け）：package-lock.json／yarn.lockなどを厳格に使い、CIではnpm ci／yarn --frozen-lockfileを使って再現性を確保する。
- 署名・provenanceの検証：ダウンロード時に署名検証やprovenanceを確認し、欠如や不整合があればブロックする。
- ランタイム・インストール監視：開発マシンやビルドランナーでの不審なネットワーク接続、ファイル作成、外部スクリプト実行をEDR/CIログで監視する。
- インシデント対応プレイブック：侵害が特定された依存を含むプロジェクトのビルド履歴・CI実行履歴・影響範囲（SBOM参照）を即時抽出できるようにする。
これらは単発の対策ではなく、SBOM・SLSA・署名ツール（sigstore/cosign等）を組み合わせた「検出→検証→封じ込め→復旧」のワークフロー設計が鍵になります。
運用への落とし込み：自動化と優先度付け
継続的な監視を実現するには以下を優先してください。
- 高優先度（直ちに実装）：SBOM生成の自動化、lockfile運用、署名検証のCI組込み、メンテナアカウントの多要素化。これらは発見から封じ込めまでの時間を短縮します。
- 中期（数週間〜数月）：SLSAレベルに沿ったビルド基盤の改善、透明性ログへの常時登録、プロジェクト横断の依存監査ダッシュボード構築。
- 長期（継続改善）：プロバイダ間でのSBOM共有方針策定、サプライヤー評価基準の導入、コミュニティとの脅威インテリ共有。組織はこれらをポリシー化して発注側・受託側のSLAに組み込むべきです。
最後に：脅威は変化します。近年観測されるように、攻撃者は短期間に多数のパッケージを毒す手法や自律拡散型（ワーム化）戦術へと戦術を進化させています。したがって、単発のスキャンでは不十分であり、シグナル相関とビルド/配布の整合性検証を組み合わせた運用が不可欠です。組織はまず最小限の自動化（SBOM＋署名検証＋postinstall監視）を導入し、その上でSLSAレベル向上やCIの分離・最小権限化を進めてください。
参考情報（詳細調査や導入時に参照すべき一次情報）: Sigstore/Cosign の導入動向、SLSAのガイドライン、NIST／CISAのSBOM方針を確認してください。