Mastra依存に忍び込んだ「easy-day-js」─ postinstallで二段階ペイロードを呼び込む供給網攻撃です

今日の深掘りポイント

• dayjsを装う「easy-day-js」がMastraエコシステムの依存に混入し、postinstallで第二段階を取得しようとする設計です。
• 依存を外すだけでは不十分で、導入先ホスト（開発端末・CIランナー・ビルドエージェント・本番）を暫定的に侵害前提で調査すべき事案です。
• 攻撃は「パッケージをimportしなくても成立」するため、lockfile監査・スクリプトの既定無効化・CIのネットワーク最小化が決定打になります。
• 速やかな範囲特定と認証情報のローテーション、そしてパイプラインのポリシー強化が再発防止の中心です。
• 目先の駆除より「どこで、なにが、いつ動いたか」の証跡再構成が価値を生みます。脅威は即応性が高く、アクションの具体化が勝敗を分けます。

はじめに

ソフトウェア供給網の脅威は、もはや開発チームの「外側」から来るとは限らないです。npmといった信頼のエコシステムそのものが運搬路になり、しかも依存の奥底で静かに作動します。今回報告された「easy-day-js」は、人気のdayjsを装い、Mastraの複数パッケージの依存関係として取り込まれ、インストール時のpostinstallスクリプトから第二段階のペイロード取得を狙ったとされています。開発現場からCI、そして必要なら本番にまで到達する“横糸”を担うのが依存関係であり、だからこそ初期対応と恒久対策の質が問われます。

本稿では公開情報を起点に、技術的な事実関係と、経営・運用の意思決定に資する示唆を切り分けて整理します。

参考情報:

• Sonatype: easy-day-jsがMastraを標的にした依存関係攻撃の増加です（2026-06-17）https://www.sonatype.com/blog/easy-day-js-targets-mastra-dependency-attacks-grow

深掘り詳細

事実（一次情報に基づく整理）

• npmパッケージ「easy-day-js」は人気ライブラリdayjsを装い、Mastra関連パッケージの依存に加えられたと報告されていますです。
• インストール後に自動で実行されるpostinstallスクリプトを悪用し、攻撃者インフラから第二段階ペイロードをダウンロード・実行しようとする挙動が確認されていますです。
• この攻撃はパッケージをimportしなくても、インストールの時点で成立します。つまりビルドフェーズ（開発端末・CI・ビルドエージェント・本番導入時の依存解決）で動作するリスクがありますです。
• 影響ホストは単にパッケージを削除しただけでは安全とは言えず、証跡確認が完了するまでは侵害の可能性を前提に扱うべきと示されていますです。
• 以上はSonatypeの公開分析に基づくもので、現時点で最も一次に近い公開情報のひとつです。Sonatype記事を参照くださいです。

インサイト（編集部の考察と仮説）

• なぜAIフレームワークか（仮説）: 攻撃者は「開発者が素早く試す」領域を好みます。生成AI・エージェント系フレームワークは新規プロジェクトや個人検証が多く、審査ゲートや制限の薄い開発端末・セルフホストCIに届きやすいです。トレンドを踏まえれば、AI関連のnpmエコシステムは今後も標的選好が続く可能性が高いです。
• 依存に“静かに”侵入する意味: postinstallは「ビルドを成功させるための正当な行為」に見せかけられます。しかもimport不要です。CIで“テストが回る＝安全”という思い込みを逆手に取り、「ビルド完了時にはもう遅い」状態をつくることができます。
• 「削除して終わり」を否定する理由: postinstallが動いた瞬間に、環境変数やローカル設定に残る機密（PAT、クラウドキー、NPMトークン、レジストリ資格情報など）が引き抜かれた可能性があります。たとえ第二段階取得が失敗しても、一次スクリプトだけで情報収集・送信を試みる設計は十分にあり得ます。よって範囲特定と資格情報の強制ローテーションはセットで考えるべきです。
• メトリクスの含意: 本件は即応性・実行可能性が高く、いま動ける組織ほど被害を限定できます。逆に、楽観よりも「広く・速く・体系的に」手を動かす姿勢が合理的です。CISOは「全社でのスコーピング」と「CIのスクリプト既定無効化」を当座のKPIに置くのが現実的です。

脅威シナリオと影響

以下は公開情報と一般的な攻撃パターンに基づく仮説シナリオです。個別環境での成立可否は証跡により評価してくださいです。

• シナリオA: 開発端末からの資格情報奪取と横展開（仮説）
  • 依存解決時のpostinstallが、環境変数やキーチェーンに残るトークンを収集し外部送信します。
  • その後、GitHub/GitLabへの不正アクセス、レジストリ書き換え、別リポジトリへのマルウェア注入に進展します。
• シナリオB: CIランナーの汚染とアーティファクト汚染（仮説）
  • 一時ランナーでもpostinstallが実行され、キャッシュやジョブログに機密が出力される可能性があります。
  • 攻撃者はビルド成果物やコンテナに不正コードを混入し、下流の本番環境へ移送します。
• シナリオC: 本番導入時の「静的」依存解決での実行（仮説）
  • 一部の導入プロセスは本番で依存解決を行います。postinstallが実行され、本番資格情報の直接流出が起き得ます。

MITRE ATT&CK（仮説マッピング）

• 初期侵入／信頼悪用: Supply Chain Compromise（T1195）です
• 実行: Command and Scripting Interpreter（JavaScript/Node, PowerShell, Bash）（T1059系）です
• 偽装: Masquerading（パッケージ名の擬態）（T1036）です
• ツール搬入: Ingress Tool Transfer（第二段階取得）（T1105）です
• 発見: System Information Discovery（T1082）です
• 資格情報アクセス: Unsecured Credentials（Credentials in Environment Variables 等）（T1552.003）です
• C2: Application Layer Protocol: Web（T1071.001）です
• データ流出: Exfiltration Over C2 Channel（T1041）です
• 永続化（可能性）: Boot or Logon Autostart Execution（レジストリRun/スケジュールタスク等）（T1547/T1053）です

影響評価の勘所

• 技術的影響: 機密トークンの漏えい、レジストリ・ソースコード・アーティファクトの改ざん、サプライチェーン下流への伝播です。
• 事業的影響: リリース停止、顧客向けアーティファクトのリコール、コンプライアンス報告、ブランド毀損コストです。
• 捜査難度: インポート不要でpostinstallが動くため、アプリ実行面のテレメトリだけでは検知しづらいです。依存解決フェーズの監査ログが決定的です。

セキュリティ担当者のアクション

時間軸に沿った優先順位で提示します。自社のリスク許容度に応じて調整してくださいです。

1. 影響範囲の即時スコーピング（全社横断）

• リポジトリ・モノレポ・テンプレートのロックファイルを一括検索します。
  • grep例: grep -R "easy-day-js" -n {repo_root} です
  • npm: npm ls easy-day-js || true です
  • yarn: yarn why easy-day-js || true です
  • pnpm: pnpm why easy-day-js || true です
• アーティファクト／コンテナ素材のSBOM検索を実施します。SBOMが無い場合はこの機会に生成を標準化します。
• パッケージキャッシュ・ローカルNodeプロジェクトの横断検索（開発端末のホームディレクトリ配下）を行います。

2. 導入ホストの暫定隔離とトリアージ

• easy-day-jsがインストールされた可能性のあるホスト（開発端末、セルフホストCI、ビルドエージェント、本番）を暫定的に侵害前提で扱います。
• 重点ログ・痕跡（例）
  • インストール直後のネットワーク外向き通信（親プロセスが npm/node/yarn/pnpm、子に curl/wget/powershell/cmd/bash 等）です
  • ホーム配下の .npm/_logs、CIのインストールログ、プロセス監査ログ（Sysmon/EDR）です
  • 新規作成の起動タスク（Windows Task Scheduler、cron/systemd）やレジストリRunキーです
• 二段階取得先のドメイン/IPは公開情報に依存するため、入手できたIOCは早期にブロックリストへ投入します（社内TIP/EDR/ゲートウェイに反映）です。

3. 認証情報のローテーションと強制失効

• 影響端末・CIで利用しうる以下を速やかにローテーションします。
  • GitHub/GitLabのPAT・デプロイトークン、NPM/内部レジストリのトークン、クラウド（AWS/GCP/Azure）キー、コンテナレジストリ（GHCR/ECR/GCR等）の資格情報です
• SSO・MFA再登録や、リポジトリの保護ブランチ・署名必須設定（required signing/verified publisher）を再点検します。

4. CI/CDの既定安全化（再発防止の決定打）

• 依存解決時のスクリプトを既定で無効化します。
  • npm: npm ci --ignore-scripts です
  • yarn: yarn install --ignore-scripts です
  • pnpm: pnpm install --ignore-scripts です
• ロックファイル固定を徹底します。
  • npm: npm ci（package-lock.json必須）です
  • yarn/pnpm: --frozen-lockfile です
• ネットワーク最小化をCIで実施します。
  • 依存解決フェーズはレジストリと署名/キャッシュ以外の外向きを遮断します（egress allowlist）です
• レジストリ制御
  • 公式レジストリ/社内プロキシのみを許可し、スコープ外レジストリを遮断します。
• 依存のポリシー強制
  • npm/pnpmのoverridesやyarn resolutionsで easy-day-js を禁止（ダミーバージョンやローカル安全パッケージへ強制）します。
  • postinstall等のライフサイクルスクリプトを含む新規依存は、コードオーナー承認・自動スキャン（挙動/評判）をパスしないとマージできないようゲート化します。

5. 検知と可観測性

• SIEM/EDRでのハンティングクエリを常設します。
  • 親が npm/node/yarn/pnpm のプロセスから、ネットワークツール（curl, wget, powershell, cmd, bash）が起動し、外向き通信した事象です
  • CIセグメントから未知ドメインへのHTTP/HTTPSトラフィック（UAにnpm/yarn/pnpm/Nodeが現れる）です
• 依存解決フェーズの監査ログを標準化し、タイムライン再構成のコストを下げます。

6. アーキテクチャの耐性向上（中期）

• 環境変数での長期キー常駐を廃し、OIDC連携や短寿命トークンに移行します。
• ビルドとテストをネットワーク分離し、postinstallがあっても外部と通信できない段階でのみ許可します。
• パッケージ発行元の真正性検証（利用可能な場合のプロビナンス/署名）と、成果物（コンテナ/バイナリ）の署名・検証をSREに組み込みます。

最後に

• 依存関係は“目に見えない境界”を自在にまたぐため、被害範囲の見積もりを過小評価しがちです。今回は即応性と実行可能性が高い脅威で、早期にスコープを確定し、資格情報をローテーションし、CIの既定を「スクリプト無効＋外向き最小化」に切り替えることで、実害と検知コストを大幅に圧縮できます。開発体験を損なわない範囲で「デフォルト安全」を敷くことが、次の一手を軽くする最短経路です。

参考情報:

• Sonatype: easy-day-jsがMastraを標的にした依存関係攻撃の増加です（2026-06-17）https://www.sonatype.com/blog/easy-day-js-targets-mastra-dependency-attacks-grow