サプライチェーン攻撃の実態解明とカナリーの防衛戦略

はじめに

2025 年 9 月中旬、npm パッケージマネージャでサプライチェーン攻撃が連続して発生しました。開発に欠かせないツールが標的になったこの事件は、多くのエンジニアにとって他人事ではありません。この記事では、攻撃の仕組みと実被害をわかりやすく解説するとともに、Canary がどう備えているかを共有します。私たちの取り組みが、みなさんのセキュリティ対策のヒントになれば幸いです。

攻撃の全体像

今回の攻撃は、フィッシングから始まりました。攻撃者はパッケージのメンテナに巧妙なフィッシングメールを送り、認証情報を盗み出して、正規パッケージに悪意あるコードを仕込んでいきました。

攻撃の流れ

1. 攻撃者が npm パッケージのメンテナにフィッシングメールを送付^[1]
2. メンテナが npm 公式サイトを装った偽サイト(攻撃者が巧妙に作成)に認証情報を入力
3. 攻撃者が盗んだ認証情報で npm アカウントに不正ログイン
4. 悪意のあるコードを含む新バージョンを正規パッケージとして公開
5. 利用者が改ざんされたパッケージをダウンロードしてインストール
6. マルウェアが実行され、暗号通貨トークンや個人情報などの機密情報を窃取

以下のように図式化できます。

このような攻撃を未然に防ぐため、私たち全員が常に警戒を怠らず、セキュリティ対策を継続的に強化していくことが重要です。

Canary の具体的な対策

1) 依存パッケージを安全に最新化する運用

Canary では Renovate を活用して npm パッケージの継続的な更新を行っています。その際、minimumReleaseAge に一定の待機期間を設定することで、パッケージ更新直後の即座の適用を避けるようにしています。これにより早期の不具合を回避し、コミュニティのフィードバックを待ってから安全に取り込むことができます。社内での Renovate の運用について詳しくは、こちらのブログ「チームで運用する Renovate の勘所」を参照してみてください。

2) 早期検知のための情報収集

セキュリティの脅威は日々進化しているため、最新情報のキャッチアップが欠かせません。SNS(例えば x.com)では、いち早く情報を得られる利点があります。ただし、SNS 上の情報は未検証のものも含まれるため、鵜呑みにせず、必ず公式な情報源で裏付けを取ることが重要です。以下では、より詳細で信頼性の高いセキュリティ情報を入手できる公式サイトをご紹介します。

• CISA Known Exploited Vulnerabilities Catalog
  • 米国 CISA が管理する「実際に攻撃で悪用された脆弱性」だけを集めたカタログです。
• JVN iPedia(脆弱性対策情報データベース)
  • IPA が運営する日本語の脆弱性データベース。2025 年 11 月時点で 25 万件以上の情報があり、日本国内製品の脆弱性も豊富に扱っています。
  • 海外の情報も日本語で読めるため、チーム内での情報共有がスムーズです。
• GitHub Security Advisory Database
  • オープンソース向けのセキュリティ情報データベース。この 5 年でレビュー済みアドバイザリが 400 件から 2 万件超に急成長しており、コミュニティ主導で活発に更新されています。
• NVD (National Vulnerability Database)
  • 米国 NIST が運営する脆弱性情報の総本山。CVE の詳細情報を網羅的に提供しており、自動化ツールとの連携にも優れています。

Canary では、これらの情報源を日常的にチェックして最新の脅威動向を把握しています。パッケージに侵害が見つかった場合は、すぐにチーム内で共有し、各プロダクトで迅速に対応しています。

3) 社内の相談・報告経路を明確化

セキュリティインシデントにおいて最も危険なのは初動の遅延です。そのため、Canary では「迷ったらすぐ相談」という文化を徹底しています。社内に「情報セキュリティ相談・報告窓口」を設置し、セキュリティインシデントが疑われる場合や SNS で気になる情報を発見した場合に、すぐ連絡できる Slack チャンネルとメールを整備しています。判断に迷う時間を極力減らし、専門チームへ早期にエスカレーションすることで、被害を最小限に抑えられる体制を作っています。

4) AI による PR レビューと Artifact Registry の脆弱性スキャン(自動化)

人間の判断だけでは見落としが発生するため、自動化による多層防御も取り入れています。ライブラリアップデートの PR が作成されるたびに、GitHub Actions のワークフローが自動的に起動し、更新されるライブラリの脆弱性スキャンや CVE 情報の確認、サプライチェーン攻撃リスクの簡易評価を実施します。検出結果は PR に自動コメントされるため、レビュアーは即座にリスクを把握できます。

さらに、Artifact Registry と Security Command Center を組み合わせて、コンテナイメージの脆弱性を継続的に監視しています。デプロイ後に新しい脆弱性が見つかった場合でも自動で通知されるため、常に最新のセキュリティ状況を把握できます。これにより、プロジェクト全体のセキュリティリスクを一元管理し、迅速に対応できる体制を整えています。

まとめ

セキュリティは単なる技術の問題ではなく、サービスの信頼性やユーザーとの信頼関係を左右する重要な課題です。一度失った信頼を取り戻すのは簡単ではありません。

対策を進める際は、すべてを一度に完璧にする必要はありません。リスクの大きさを見極めながら、チームの状況に合わせて優先順位をつけ、できることから着実に取り組んでいくのが現実的です。

本記事で紹介した対策や情報源が、みなさんのチームでセキュリティ文化を築くきっかけになれば幸いです。完璧な防御策は存在しませんが、日頃からセキュリティを意識し、チーム全体で継続的に改善していく姿勢こそが、最も強固な防御になります 💪。

脚注

1. フィッシングメールの内容