サプライチェーン攻撃

Supply Chain Attack

security development beginner

取引先やソフトウェアの供給経路などを経由して、標的の組織や利用者を攻撃する手口。

概要（サマリー）

サプライチェーン攻撃とは、取引先やソフトウェアの供給経路などを経由して、標的の組織や利用者を攻撃する手口である。
正面の入口を狙うだけでなく、出入りを許された業者や、普段受け取る部品に目を付けるイメージだ。
企業の委託先だけでなく、個人開発で利用する外部のソフトや部品も関係する。

サプライチェーンは、製品やサービスが届くまでの供給のつながりを意味する。
ITでは、外部の開発会社、運用委託先、ソフトの配布元などが関係する。

自分のシステムが安全でも、接続を許可した相手の環境が侵害される場合がある。
共有アカウントや管理用の接続を通じて、攻撃が届くおそれがあるのだ。

そのため、守る範囲を自社の機器だけに限定できない。
誰に何を任せ、どの接続や情報を渡しているかも把握する必要がある。

アプリは、自分で書いたコードだけで動いているとは限らない。
外部のパッケージやライブラリを組み合わせて作られることが多い。

利用した部品が別の部品を必要とする関係を、依存関係と呼ぶ。
自分が直接選んでいない部品も、間接的に取り込まれている場合がある。

配布元や開発者のアカウントが奪われると、正規の名前で不正な更新が配布されることがある。
「いつもの配布元だから」という信頼が、攻撃に利用されるわけだ。

ソフトの更新は、通常は安全性を高めるための大切な作業だ。
しかし、更新を作る環境や配布の仕組みが侵害されると、そこへ不正な処理を混ぜられる場合がある。

過去の例では、ネットワーク管理ソフトSolarWindsの正規の更新に、不正な処理が仕込まれた。
別の例では、多くの環境が使う圧縮の部品XZ Utilsの開発過程に、不正な変更が入り込んだ。
どちらも、利用者が普段の入手先から受け取ったものだった。

コードの検査から公開までを自動化するCI/CDも、保護すべき工程である。
公開に使う権限が奪われれば、多数の利用者へ影響が広がりうる。

これは「更新しないほうが安全」という意味ではない。
更新の確認、権限の制限、問題発生時に戻せる手順を組み合わせることが重要だ。

個人開発では、まず自分のプロジェクトが使う部品を確認するところから始められる。
次は、npmを使う既存プロジェクトのフォルダで実行する例である。

npm ls --depth=0
npm audit

最初のコマンドは、直接利用しているパッケージを表示する。
次のコマンドは、依存関係について報告済みの脆弱性を確認するためのものだ。

npm audit は、依存パッケージの情報を設定先のレジストリへ送信して検査する。
社内プロジェクトでは利用ルールを確認し、検出がゼロでも不正な部品をすべて見抜けるわけではないと理解して使う。

よく似た名前の偽パッケージへ誘導する攻撃もある。
検索結果の順位やダウンロード数だけで判断せず、公式の案内と配布元を照合する。

バージョンや依存関係を記録するロックファイルは、同じ構成を再現する助けになる。
ただし、記録した時点で部品が不正なら、その状態も再現される。

開発環境に置くAPIキーなどの秘密情報も、必要な範囲に絞る。
部品が不正な処理をしても、公開先のすべてを操作できないようにする考え方だ。

業務を外部へ任せる場合は、どの情報と権限を渡しているかを整理する。
契約が終わったアカウントや、不要になった接続を残さないことも大切だ。

事故が起きたときに、誰が誰へ連絡するかを事前に決めておく。
調査結果や影響範囲を共有できる体制も、技術的な対策と同じくらい役に立つ。

外部サービスを使わないことが目的ではない。
つながりを把握し、必要以上の権限や情報を渡さないことが基本となる。

AIが提案したパッケージ名は、そのままインストールせず、実在性と公式の配布元を確認する。
不要な依存関係を増やさず、何のために導入する部品か説明してもらうとよい。

たとえば「この機能に必要な依存関係と採用理由を整理し、既存機能だけで実装できる案も示して」と依頼できる。
AIの回答だけで安全と判断せず、公式情報と依存関係の差分を確認して採用する。

委託先として狙われる場合も、外部ソフトの利用者として影響を受ける場合もある。
組織の大きさだけで対象外にはならない。

正規の管理者アカウントや公開工程が侵害される場合もある。
知名度は判断材料の一つだが、安全の保証ではない。

既知の脆弱性を調べる検査と、不正な処理の有無を見極める作業は異なる。
検査結果に加えて、配布元や変更内容、必要な権限も確認する。