攻撃者が狙うのは本番環境より「開発者」 npm installするだけで侵害される時代の守り方：開発者が“最も効率的な侵入ルート”にされる理由

OSSに悪性コードが混入するソフトウェアサプライチェーン攻撃が、開発現場を大きく揺るがしている。開発者を「最も効率的な侵入ルート」と見なす構造的な背景を解説し、OSSを活用したソフトウェア開発プロセスの盲点を明らかにする。

[前田友樹（JFrog Japan），＠IT]

　昨今、「Mini Shai-Hulud」をはじめとする、オープンソースソフトウェア（以下、OSS）に悪性コードが混入するソフトウェアサプライチェーン攻撃が、開発現場を大きく揺るがしています。インターネット上で無料公開され、世界中で利用されている「npm」「PyPI」などのパッケージに、いつの間にかマルウェアが混入し、取り込んだ端末やCI/CD（継続的インテグレーション／継続的デリバリー）ツールから機密情報が窃取される事故が後を絶ちません。

　攻撃者にとっては、堅牢（けんろう）な本番環境よりも、高い権限を持ちながらOSSを迅速に追加、活用することが多い開発者の端末やCI/CDツールを狙う方が合理的です。開発者環境への侵害は、ステージング／本番環境のデータベース（以下、DB）へのフリーパスにつながります。

　本記事では、開発者を「最も効率的な侵入ルート」と見なす構造的な背景を解説し、OSSを活用したソフトウェア開発プロセスの盲点を明らかにします。その上で、開発者を起点とする攻撃の連鎖を断つソフトウェアサプライチェーンセキュリティの在り方を提言します。

Mini Shai-Huludなどの事例が示す、従来と大きく異なる問題点

　OSSの流通経路を悪用したソフトウェアサプライチェーン攻撃が、現実的な脅威として定着しました。攻撃者は本番環境を正面突破するのではなく、広く使われるnpm、PyPIなどのパッケージレジストリやOSSの依存関係に紛れ込み、開発者の端末で正規の開発行為に見せ欠けて侵入を成立させます。

　Mini Shai-Huludのような事例で共通するのは、まずOSSパッケージを汚染し、取り込んだ開発者の環境で次の攻撃につなげる点です。混入するコードは派手な破壊活動よりも、機密情報窃取やリモート実行の足掛かりを作るものが多く、発覚が遅れやすい傾向があります。

　重要なのは、被害の入り口が本番環境ではなく、日常の開発で必ず利用する「install」「build」といったコマンドにあることです。開発者が普段通りOSSパッケージをインストールするだけで、侵害が発生し得るのです。だからこそ、本番環境を中心とした従来の対策だけでは、ソフトウェアサプライチェーンのリスクに対応し切れません。

開発者が“最も効率的な侵入ルート”にされる理由

　攻撃者の目的は、暗号化されたデータそのものを盗むことよりも、「そのデータに対して正規の手段でアクセスできる権限」を手に入れることにあります。

　たとえデータベースの中身が暗号化されていても、開発者は基本的に復号済みのデータを扱うことができ、開発者が持っている“データを読み取る権限”を奪うだけで攻撃者にとっては十分だからです。開発者はこの意味で、狙われやすい位置にいます。

　開発者の端末は、業務上どうしても多くの機密情報が集まりやすく、攻撃者にとって宝の山になります。例として、以下のような情報が開発者の手元に集まりやすい傾向にあります。

• 「Amazon Web Services」（AWS）、「Microsoft Azure」「Google Cloud」といったクラウドサービスプロバイダーの認証情報
• APIトークン、DBの接続情報
• 「GitHub」「GitLab」といったVCS（Version Control System）サービスの認証情報
• 本番／ステージング環境に接続するための踏み台の認証情報

　さらに攻撃者にとって都合が良いのは、開発現場には「早く試す」「まず動かす」という文化があり、OSSの依存パッケージの追加や変更が高速に行われる点です。急ぎの検証、暫定対応などといった、日々の作業が抜け道になります。攻撃者が開発者を狙うのは、それが攻撃にとって合理的な“最短距離”だからなのです。

悪性OSSが開発端末に入るまで（開発プロセスの盲点）

　悪性OSSの混入は、開発者個人のミスではなく、OSSの依存関係が膨大になった結果、チェックが追い付かないことから発生します。典型的な開発プロセスの盲点は次の通りです。

依存関係の深さ

　1つ目は、依存関係が深いことです。アプリケーションが直接利用するOSSライブラリは数十程度でも、その依存の依存まで含めると数百〜数千規模になります。攻撃者はこの層を狙い、目立たない場所に悪性コードを混入させます。

OSSの導入スピード

　2つ目は、OSSの導入が速いことです。新しいOSSライブラリは、小さな検証作業のために次々に追加されていきます。レビュー対象が増え続け、全てを人手で確認するのは現実的ではありません。侵入の手口としては、次のようなものが組み合わさります。

• タイポスクワッティング（正規のOSSと似た名前のOSSパッケージに悪性コードを混入する）
• 乗っ取り（メンテナーのアカウント侵害）
• 依存関係の汚染（人気パッケージが利用しているOSSパッケージに悪性コードを混入）

　深刻なのは、侵入が「正規のコマンド」の実行によって成立してしまう点です。「npm install」「pip install」は日常的な開発作業で使われるので、正常な開発行為と攻撃による実行を見分けるのは容易ではありません。その結果、「悪性OSSは侵入させやすい一方で、検知や抑止が難しい」という非対称なリスクを生み出します。

「GitHub Actions」「Jenkins」などのCI/CDツールは「第二の開発者端末」

　近年、開発者端末と同じくらい攻撃の対象になりやすいのがCI/CD環境です。CI/CDは「ビルドとテストをする場所」だけではなく、それ以外にも以下を実行します。

• OSSの依存関係の取得
• シークレットを利用した認証（CI/CDツール本体にシークレットをセット）
• ソースコードをビルドして生成した成果物（アーティファクト）を本番環境にデプロイ

　CI/CD環境は、機密情報が集まりやすい場所であり、「Git」へのプッシュ、プルリクエスト（PR）、タグ作成などを契機に自動でコードを実行し、ビルド中にnpmやPyPIなど組織外のコードを取得して動かす、という条件がそろった「第二の開発端末」です。

　CI/CD環境が侵害されると、単に社内環境が荒らされるだけではなく、正規のビルド成果物として悪性コードが社外にも配布され得ます（※）。これはサプライチェーン攻撃の供給側に回ることを意味し、被害規模が跳ね上がる可能性があります。

※参考：大手企業が次々と被害に　ソーラーウィンズから連鎖した「サプライチェーン攻撃」の脅威

今後のソフトウェアサプライチェーンセキュリティ

　ここまで見てきた通り、最新のソフトウェアサプライチェーン攻撃は、開発端末とCI/CD環境が「強い権限を持つ実行環境」になっている構造を突いて成立します。従って、その対策は、開発者の注意や個別のレビューに寄せるのではなく、依存関係の取得からビルド成果物の配布までをアーティファクト（成果物）管理ツールを使って中央で統制し、ルールを自動適用する方向に寄せるのが現実的です。

OSSをインターネットから直接取得するのをやめ、依存取得を一元管理

　悪性OSS混入の多くは、各開発者やCI/CDツールがnpmやPyPIなどへ直接アクセスして依存を取得する構造から起きます。まずは依存取得の経路を統一し、アーティファクト管理ツールを経由させます。

• 開発者端末とCI/CDツールは「OSSレジストリへ直接アクセスしない」を原則にする
• 依存取得のログがアーティファクト管理ツールに集まるので、「いつ、誰が、何を取ったか」を後追いできる

　これにより、依存関係が野良ルートで入ってくることを抑え、後述の検査・ブロックが効く土台ができます。

依存パッケージの“入り口”で自動検査し、危険物をブロック

　人手承認の代わりに、OSSの依存関係が入ってくる際に機械的に判定します。

• CVSS（Common Vulnerability Scoring System、共通脆弱性評価システム）などの既知脆弱（ぜいじゃく）性に基づくポリシー判定
  例えば、「Critical」は遮断、「High」は例外申請が必要、「Medium」以下は許可など
• ライセンスの自動チェック
  例えば、「GPL系を禁止する」「商用利用不可ライセンスを禁止する」など
• 不審なパッケージの検知

　重要なのは、これらを検知するだけではなく「ダウンロードさせない」まで落とし込むことです。入り口で止めると、開発者端末やCIでの実行に到達しません。

成果物（アーティファクト）を1カ所に集め、デプロイ経路を統制

　「悪性コードを含んだ成果物が正規成果物として配布され得る」という問題は、配布経路が分散しているほど深刻になります。対策として、成果物を中央に集め、配布もそこから行うようにします。

• npmやPyPI、「Maven」などのパッケージ、コンテナ、Helm、汎用（はんよう）バイナリといったビルド成果物は、全てアーティファクト管理ツールにアップロードして管理する
• 本番環境へのデプロイは、原則としてアーティファクト管理ツールに登録された成果物のみを許可する
• 成果物にはメタデータ（ビルド番号、コミット、ビルド環境、依存一覧など）をひも付け、後から追跡可能にする

　これで「どこから出た成果物か不明」「個人端末やCI/CDツールから直接公開された」といった抜け道をつぶせます。

成果物がアーティファクト管理ツールに登録されたタイミングで自動スキャン

　成果物がアーティファクト管理ツールに登録されたタイミングで、依存関係や脆弱性、ライセンスの自動スキャン（SCA：Software Composition Analysis）をします。新しい脆弱性、CVE（Common Vulnerabilities and Exposures）が公開された場合は、過去に登録された成果物も含めて再評価（継続監視）し、影響を受ける成果物を即座に洗い出せるようにします。

　重要なのは、“検知”にとどめず、ポリシー違反の成果物は“隔離”し、配布やデプロイ対象から自動的に除外することです。

SBOMと脆弱性情報を成果物にひも付け、影響範囲を即座に特定できるようにする

　成果物ごとにSBOMを生成、保管しておくと、インシデントが起こったときでも、判断が高速化します。

CI/CDツールに渡すものを減らす：シークレットの一元管理と権限の調整

　アーティファクト管理ツールの運用体制が整うと、CI/CD環境に必要な権限を整理しやすくなります。CI/CD環境には、アーティファクト管理ツールに対するアップロードやダウンロードの権限を持たせ、本番環境へのデプロイは「アーティファクト管理ツールに登録された、検査済みの成果物だけ」を対象にします。

　加えて、できればCI/CDツールに直接トークンなどの認証情報をセットせず、別のシークレット管理ツールに保管するなどの対策が望ましいです。CI/CD環境を何でもできる特権環境にしないことが、現実的な落としどころです。

まとめ

　ソフトウェアサプライチェーン攻撃は、開発者端末やCI/CDツールの中にある、“どこか1カ所”の守りを固めるだけでは防ぎ切れません。効果が出やすいのは、次の2点を中央で押さえることです。

1. 依存関係の入り口：外部から入ってくるOSSパッケージを検査し、危険なパッケージは入れない
2. 成果物（アーティファクト）の出口：成果物のデプロイ経路を統制し、検査済みのものだけを流す

　この「入り口」と「出口」を管理できるようになると、開発者の速度を落とさずに、悪性OSS混入やCI侵害の被害連鎖を断ちやすくなります。開発者の行動を制限するのではなく、開発者が安全に開発できるソフトウェアサプライチェーンセキュリティを設計、構築することが、これからの現実解です。

筆者紹介

---

前田 友樹（まえだ　ともき）

シニアソリューションエンジニア／JFrog Japan株式会社

SIerおよびWeb系企業でのアプリケーション開発を経て、SaaS導入コンサルタント・プリセールスエンジニアとして多数の企業支援に従事。現在はJFrog Japanにてソリューションエンジニアとして開発体制の高度化を支援。福岡県北九州市出身。